Partager via

ID de modèle utilisateur d’application (AppUserModelIDs)

  • Article

Les ID de modèle utilisateur d’application (AppUserModelIDs) sont largement utilisés par la barre des tâches dans les systèmes Windows 7 et versions ultérieures pour associer des processus, des fichiers et des fenêtres à une application particulière. Dans certains cas, il suffit de s’appuyer sur l’AppUserModelID interne affecté à un processus par le système. Toutefois, une application qui possède plusieurs processus ou une application qui s’exécute dans un processus hôte peut avoir besoin de s’identifier explicitement afin qu’elle puisse regrouper ses fenêtres par ailleurs disparates sous un seul bouton de barre des tâches et contrôler le contenu de la liste de raccourcis de cette application.

Application-Defined et System-Defined AppUserModelIDs

Certaines applications ne déclarent pas un AppUserModelID explicite. Elles sont facultatives. Dans ce cas, le système utilise une série d’heuristiques pour affecter un AppUserModelID interne. Toutefois, il existe un avantage en matière de performances à éviter ces calculs et un AppUserModelID explicite est le seul moyen de garantir une expérience utilisateur exacte. Par conséquent, il est vivement recommandé de définir un ID explicite. Les applications ne peuvent pas récupérer un AppUserModelID attribué par le système.

Si une application utilise un AppUserModelID explicite, elle doit également affecter le même AppUserModelID à toutes les fenêtres ou processus en cours d’exécution, raccourcis et associations de fichiers. Elle doit également utiliser cette AppUserModelID lors de la personnalisation de sa liste de raccourcis via ICustomDestinationList et dans tous les appels à SHAddToRecentDocs.

Notes

Si les applications n’ont pas d’AppUserModelID explicite, elles doivent appeler les méthodes IApplicationDestinations, IApplicationDocumentLists et ICustomDestinationList , ainsi que SHAddToRecentDocs à partir de l’application. Si ces méthodes sont appelées à partir d’un autre processus, tel qu’un programme d’installation ou un programme de désinstallation, le système ne peut pas générer l’AppUserModelID correct et ces appels n’auront aucun effet.

 

Les éléments suivants décrivent des scénarios courants qui nécessitent un AppUserModelID explicite. Ils indiquent également les cas où plusieurs AppUserModelID explicites doivent être utilisés.

  • Un fichier exécutable unique avec une interface utilisateur avec plusieurs modes qui apparaissent pour l’utilisateur comme des applications distinctes doit affecter des AppUserModelIDs différents à chaque mode. Par instance, une partie d’une application que les utilisateurs considèrent comme une expérience indépendante qu’ils peuvent épingler et lancer à partir de la barre des tâches séparément du reste de l’application doit avoir son propre AppUserModelID, distinct de l’expérience main.

  • Plusieurs raccourcis avec des arguments différents qui mènent tous à ce que l’utilisateur voit comme la même application doivent utiliser un seul AppUserModelID pour tous les raccourcis. Par exemple, Windows Internet Explorer a différents raccourcis pour différents modes (par exemple, le lancement sans modules complémentaires), mais ils doivent tous apparaître pour l’utilisateur comme un seul Explorer instance Internet.

  • Un exécutable qui agit comme un processus hôte et exécute le contenu cible en tant qu’application doit s’inscrire en tant qu’application hôte, après quoi il peut affecter différents AppUserModelID à chaque expérience perçue qu’il héberge. Le processus hôte peut également autoriser le programme hébergé à définir ses AppUserModelIDs. Dans les deux cas, le processus hôte doit conserver un enregistrement de la source des AppUserModelIDs, soit lui-même, soit l’application hébergée. Dans ce cas, il n’existe aucune expérience utilisateur principale du processus hôte sans le contenu cible. Par exemple, les applications Windows Remote Applications Integrated Local (RAIL), Java Runtime, RunDLL32.exe ou DLLHost.exe.

    Dans le cas d’applications hébergées existantes, le système tente d’identifier les expériences individuelles, mais les nouvelles applications doivent utiliser des AppUserModelID explicites pour garantir l’expérience utilisateur prévue.

  • Les processus coopératifs ou chaînés qui font partie de la même application pour l’utilisateur doivent avoir le même AppUserModelID appliqué à chaque processus. Les exemples incluent les jeux avec un processus de lanceur (chaîné) et Microsoft Lecteur multimédia Windows, qui a une expérience de première exécution/installation s’exécutant dans un processus et l’application main s’exécutant dans un autre processus (coopératif).

  • Une extension d’espace de noms Shell qui agit comme une application distincte pour plus que la navigation et la gestion du contenu dans Windows Explorer doit affecter un AppUserModelID dans ses propriétés de dossier. La Panneau de configuration en est un exemple.

  • Dans un environnement de virtualisation tel qu’une infrastructure de déploiement, l’environnement de virtualisation doit affecter différents AppUserModelIDs à chaque application qu’il gère. Dans ce cas, un lanceur d’applications utilise un processus intermédiaire pour configurer l’environnement, puis transfère l’opération à un autre processus pour exécuter l’application. Notez que cela empêche le système de lier le processus cible en cours d’exécution au raccourci, car le raccourci pointe vers le processus intermédiaire.

    Si une application a plusieurs fenêtres, raccourcis ou processus, l’AppUserModelID attribué à cette application doit également être appliqué à chacun de ces éléments par l’environnement de virtualisation.

    L’infrastructure ClickOnce est un exemple de cette situation, qui attribue correctement des AppUserModelID pour le compte des applications qu’elle gère. Comme dans tous ces environnements, les applications déployées et gérées par ClickOnce ne doivent pas attribuer elles-mêmes des AppUserModelID explicites, car cela va entrer en conflit avec les AppUserModelIDs attribués par ClickOnce et entraîner des résultats inattendus.

Comment former un Application-Defined AppUserModelID

Une application doit fournir son AppUserModelID sous la forme suivante. Il ne peut pas contenir plus de 128 caractères et ne peut pas contenir d’espaces. Chaque section doit être cased pascal.

CompanyName.ProductName.SubProduct.VersionInformation

CompanyName et ProductName doivent toujours être utilisés, tandis que les SubProduct parties et VersionInformation sont facultatives et dépendent des exigences de l’application. SubProductpermet à une application main qui se compose de plusieurs sous-applications de fournir un bouton de barre des tâches distinct pour chaque sous-application et les fenêtres associées. VersionInformation permet à deux versions d’une application de coexister tout en étant considérées comme des entités discrètes. Si une application n’est pas destinée à être utilisée de cette façon, VersionInformation le doit être omis afin qu’une version mise à niveau puisse utiliser le même AppUserModelID que la version qu’elle a remplacée.

Emplacement d’affectation d’un AppUserModelID

Lorsqu’une application utilise un ou plusieurs AppUserModelID explicites, elle doit appliquer ces AppUserModelID aux emplacements et situations suivants :

  • Dans la System.AppUserModel.ID propriété du fichier de raccourcis de l’application. Un raccourci (en tant que fichier IShellLink, CLSID_ShellLink ou .lnk) prend en charge les propriétés via IPropertyStore et d’autres mécanismes de définition de propriété utilisés dans l’ensemble de l’interpréteur de commandes. Cela permet à la barre des tâches d’identifier le raccourci approprié à épingler et garantit que les fenêtres appartenant au processus sont correctement associées à ce bouton de barre des tâches.

    Notes

    La propriété System.AppUserModel.ID doit être appliquée à un raccourci lors de la création de ce raccourci. Lorsque vous utilisez Microsoft Windows Installer (MSI) pour installer l’application, la table MsiShortcutProperty permet d’appliquer l’AppUserModelID au raccourci lors de sa création lors de l’installation.

     

  • En tant que propriété de l’une des fenêtres en cours d’exécution de l’application. Cela peut être défini de l’une des deux manières suivantes :

    1. Si différentes fenêtres appartenant à un processus nécessitent des AppUserModelIDs différents pour contrôler le regroupement de la barre des tâches, utilisez SHGetPropertyStoreForWindow) pour récupérer le magasin de propriétés de la fenêtre et définir appUserModelID comme propriété de fenêtre.
    2. Si toutes les fenêtres du processus utilisent le même AppUserModelID, définissez l’AppUserModelID sur le processus via SetCurrentProcessExplicitAppUserModelID. Une application doit appeler SetCurrentProcessExplicitAppUserModelID pour définir son AppUserModelID lors de la routine de démarrage initiale d’une application avant que l’application ne présente une interface utilisateur, effectue une manipulation de ses listes de raccourcis ou effectue (ou provoque le système) un appel à SHAddToRecentDocs.

    Un AppUserModelID au niveau de la fenêtre remplace un AppUserModelID au niveau du processus.

    Lorsqu’une application définit un AppUserModelID explicite au niveau de la fenêtre, l’application peut fournir les spécificités de sa commande de relance pour son bouton de barre des tâches. Pour fournir ces informations, les propriétés suivantes sont utilisées :

    Notes

    S’il existe un raccourci pour lancer l’application, une application doit appliquer appUserModelID en tant que propriété du raccourci au lieu d’utiliser les propriétés de relance. Dans ce cas, la ligne de commande, l’icône et le texte du raccourci sont utilisés pour fournir les mêmes informations que les propriétés de relance.

     

    Un AppUserModelID explicite au niveau de la fenêtre peut également utiliser la propriété System.AppUserModel.PreventPinning pour spécifier qu’il ne doit pas être disponible pour l’épinglage ou le redémarrage.

  • Dans un appel pour personnaliser ou mettre à jour (ICustomDestinationList), récupérer (IApplicationDocumentLists) ou effacer (IApplicationDestinations) la liste de raccourcis de l’application.

  • Dans l’inscription d’association de fichiers (via son ProgID) si l’application utilise les listes de destination récentes ou fréquentes générées automatiquement par le système. Ces informations d’association sont référencées par SHAddToRecentDocs. Ces informations sont également utilisées lors de l’ajout de destinations IShellItem à des listes de raccourcis personnalisées via ICustomDestinationList::AppendCategory.

  • Dans tout appel que l’application effectue directement à SHAddToRecentDocs. Si l’application dépend de la boîte de dialogue de fichier commun pour effectuer des appels à SHAddToRecentDocs en son nom, ces appels peuvent déduire l’AppUserModelID explicite uniquement si l’AppUserModelID est défini pour l’ensemble du processus. Si l’application définit appUserModelIDs sur ses fenêtres plutôt que sur le processus, l’application doit effectuer tous les appels à SHAddToRecentDocs elle-même, avec son AppUserModelID explicite, et empêcher la boîte de dialogue de fichier commun d’effectuer ses propres appels. Cette opération doit être effectuée chaque fois qu’un élément est ouvert pour garantir l’exactitude des sections Récents et Fréquents de la liste de raccourcis de l’application.

Les éléments suivants décrivent les scénarios courants et où appliquer des AppUserModelID explicites dans ces scénarios.

  • Lorsqu’un seul processus contient plusieurs applications, utilisez SHGetPropertyStoreForWindow pour récupérer le magasin de propriétés de la fenêtre et définir appUserModelID comme propriété de fenêtre.
  • Lorsqu’une application utilise plusieurs processus, appliquez l’AppUserModelID à chaque processus. Le fait d’utiliser le même AppUserModelID sur chaque processus dépend si vous souhaitez que chaque processus apparaisse dans le cadre de l’application main ou en tant qu’entités individuelles.
  • Pour séparer certaines fenêtres d’un ensemble dans le même processus, utilisez le magasin de propriétés de la fenêtre pour appliquer un seul AppUserModelID aux fenêtres que vous souhaitez séparer, puis appliquez un autre AppUserModelID au processus. Toute fenêtre de ce processus qui n’a pas été explicitement étiquetée avec l’AppUserModelID au niveau de la fenêtre hérite de l’AppUserModelID du processus.
  • Si un type de fichier est associé à une application, affectez l’AppUserModelID dans l’inscription ProgID du type de fichier. Si un fichier exécutable unique est lancé dans différents modes qui apparaissent à l’utilisateur comme des applications distinctes, un AppUserModelID distinct est requis pour chaque mode. Dans ce cas, il doit y avoir plusieurs inscriptions ProgID pour le type de fichier, chacune avec un AppUserModelID différent.
  • Lorsqu’il existe plusieurs emplacements de raccourci à partir desquels un utilisateur peut lancer une application (dans le menu Démarrer , sur le bureau ou ailleurs), récupérez le magasin de propriétés du raccourci pour appliquer un seul AppUserModelID à tous les raccourcis en tant que propriétés de raccourci.
  • Lorsqu’un appel explicite est effectué à SHAddToRecentDocs par une application, utilisez appUserModelID dans l’appel. Lorsque la boîte de dialogue de fichier commune est utilisée pour ouvrir ou enregistrer des fichiers, SHAddToRecentDocs est appelé par la boîte de dialogue au nom de l’application. Cet appel peut déduire l’AppUserModelID explicite du processus. Toutefois, si un AppUserModelID explicite est appliqué en tant que propriété de fenêtre, la boîte de dialogue de fichier commune ne peut pas déterminer l’AppUserModelID correct. Dans ce cas, l’application elle-même doit appeler explicitement SHAddToRecentDocs et lui fournir le AppUserModelID correct. En outre, l’application doit empêcher la boîte de dialogue de fichier commun d’appeler SHAddToRecentDocs en son nom en définissant l’indicateur FOS_DONTADDTORECENT dans la méthode GetOptions de IFileOpenDialog ou IFileSaveDialog.

Inscription d’une application en tant que processus hôte

Une application peut définir l’entrée de Registre IsHostApp pour que le processus de cet exécutable soit considéré comme un processus hôte par la barre des tâches. Cela affecte ses entrées de regroupement et de liste de raccourcis par défaut.

L’exemple suivant montre l’entrée de Registre requise. Notez que la valeur n’est pas attribuée à l’entrée ; sa présence est tout ce qui est requis. Il s’agit d’une valeur REG_NULL.

HKEY_CLASSES_ROOT
   Applications
      example.exe
         IsHostApp

Si le processus lui-même ou le fichier de raccourci utilisé pour lancer le processus a un AppUserModelID explicite, la liste des processus hôtes est ignorée et l’application est traitée comme une application normale par la barre des tâches. Les fenêtres en cours d’exécution de l’application sont regroupées sous un seul bouton de barre des tâches et l’application peut être épinglée à la barre des tâches.

Si seul le nom exécutable du processus en cours d’exécution est connu, sans AppUserModelID explicite, et si cet exécutable figure dans la liste des processus hôtes, chaque instance du processus est traité comme une entité distincte pour le regroupement de la barre des tâches. Le bouton de la barre des tâches associé à un instance spécifique du processus n’affiche pas d’option épingler/désépiner ou d’icône de lancement pour une nouvelle instance du processus. Le processus n’est pas non plus éligible à l’inclusion dans la liste MFU (Most Frequently Used) du menu Démarrer . Toutefois, si le processus a été lancé via un raccourci contenant des arguments de lancement (généralement le contenu cible à héberger en tant qu'« application »), le système peut déterminer l’identité et l’application peut être épinglée et relancée.

Listes d’exclusions pour l’épinglage de la barre des tâches et les listes récentes/fréquentes

Les applications, les processus et les fenêtres peuvent choisir de se rendre indisponibles pour l’épinglage dans la barre des tâches ou pour l’inclusion dans la liste MFU du menu Démarrer . Il existe trois mécanismes pour y parvenir :

  1. Ajoutez l’entrée NoStartPage à l’inscription de l’application, comme indiqué ici :

    HKEY_CLASSES_ROOT
   Applications
      Example.exe
         NoStartPage

    Les données associées à l’entrée NoStartPage sont ignorées. Seule la présence de l’entrée est requise. Par conséquent, le type idéal pour NoStartPage est REG_NONE.

    Notez que toute utilisation d’un AppUserModelID explicite remplace l’entrée NoStartPage. Si un AppUserModelID explicite est appliqué à un raccourci, un processus ou une fenêtre, il devient épinglé et éligible pour la liste MFU du menu Démarrer .

  2. Définissez la propriété System.AppUserModel.PreventPinning sur les fenêtres et les raccourcis. Cette propriété doit être définie sur une fenêtre avant la propriété PKEY_AppUserModel_ID .

  3. Ajoutez un AppUserModelID explicite en tant que valeur sous la sous-clé de Registre suivante, comme illustré ici :

    HKEY_LOCAL_MACHINE
   Software
      Microsoft
         Windows
            CurrentVersion
               Explorer
                  FileAssociation
                     NoStartPageAppUserModelIDs
                        AppUserModelID1
                        AppUserModelID2
                        AppUserModelID3

    Chaque entrée est une valeur REG_NULL portant le nom appUserModelID. Tout AppUserModelID trouvé dans cette liste n’est pas épinglé et n’est pas éligible à l’inclusion dans la liste MFU du menu Démarrer .

N’oubliez pas que certains fichiers exécutables ainsi que les raccourcis qui contiennent certaines chaînes dans leur nom sont automatiquement exclus de l’épinglage et de l’inclusion dans la liste MFU.

Notes

Cette exclusion automatique peut être remplacée en appliquant un AppUserModelID explicite.

 

Si l’une des chaînes suivantes, quel que soit le cas, est incluse dans le nom du raccourci, le programme n’est pas épinglé et n’est pas affiché dans la liste la plus fréquemment utilisée (non applicable à Windows 10) :

  • Documentation
  • Aide
  • Installer
  • En savoir plus
  • Lisez-moi
  • Lire en premier
  • Fichier Lisezmoi
  • Supprimer
  • Programme d’installation
  • Support
  • Nouveautés

La liste suivante des programmes ne sont pas épinglés et sont exclus de la liste la plus fréquemment utilisée.

  • Applaunch.exe
  • Control.exe
  • Dfsvc.exe
  • Dllhost.exe
  • Guestmodemsg.exe
  • Hh.exe
  • Install.exe
  • Isuninst.exe
  • Lnkstub.exe
  • Mmc.exe
  • Mshta.exe
  • Msiexec.exe
  • Msoobe.exe
  • Rundll32.exe
  • Setup.exe
  • St5unst.exe
  • Unwise.exe
  • Unwise32.exe
  • Werfault.exe
  • Winhlp32.exe
  • Wlrmdr.exe
  • Wuapp.exe

Les listes précédentes sont stockées dans les valeurs de Registre suivantes.

Notes

Ces listes ne doivent pas être modifiées par les applications. Utilisez l’une des méthodes de liste d’exclusions répertoriées précédemment pour la même expérience.

 

HKEY_LOCAL_MACHINE
   Software
      Microsoft
         Windows
            CurrentVersion
               Explorer
                  FileAssociation
                     AddRemoveApps
                     HostApps

SetCurrentProcessExplicitAppUserModelID

GetCurrentProcessExplicitAppUserModelID

Extensions de la barre des tâches

ICustomDestinationList::SetAppID

IApplicationDocumentLists::SetAppID

IApplicationDestinations::SetAppID

SHGetPropertyStoreForWindow