Brevet FR2723221A1 — publié le 19960202

Procédé de reconnaissance d'objets affichés sur un écran par analyse de caractéristiques dans une interface utilisateur graphique sur ordinateur La présente invention porte en général sur la reconnaissance d'objets affichés sur un écran d'ordinateur par analyse de leurs caractéristiques dans le contexte d'une interface utilisateur graphique et plus spécialement à la reconnaissance d'objets affichés sur un écran d'ordinateur en vue d'implémenter un système d'aide sur un ordinateur qui dispose d'un environnement Windows. (Windows et Microsoft Windows sont des marques déposées propriété de la société Microsoft Corp). Les systèmes informatiques actuels disposent d'une interface utilisateur graphique (GUI pour Graphical User Interface) qui permet à l'utilisateur de contrôler l'ordinateur en utilisant un dispositif de pointage tel qu'une souris pour sélectionner et activer des objets correspondant à leurs images. Les images, ou objets, sur l'écran peuvent constituer des contrôles, comme un bouton, un ascenseur ou une barre de défilement, une icône correspondant à un programme ou à un fichier, des utilitaires ou d'autres mécanismes qui facilitent l'utilisation de l'ordinateur comme une fenêtre, etc. En d'autres termes, dans une interface utilisateur typique, chaque objet que l'on peut manipuler correspond à une image affichée sur l'écran, image que l'utilisateur peut sélectionner et activer par l'intermédiaire du clavier de la souris ou du dispositif de pointage. La sélection et l'activation des différents objets permet à l'utilisateur d'accomplir des tâches variées, comme dialoguer avec des programmes applicatifs ou passer des commandes du système d'exploitation. La plupart des interfaces utilisateur graphiques les plus répandues disposent d'un environnement fenêtré à l'écran. Chaque fenêtre constitue une zone rectangulaire sur l'écran et peut être déplacée, retaillée, minimisée, restaurée, etc., selon des procédures bien connues. Une des caractéristiques de Microsoft Windows réside dans l'implémentation du système d'aide en ligne. Le système d'aide permet à un utilisateur de recevoir de l'information en rapport des objets présents sur l'écran ou d'accéder à des informations générales en relation avec l'usage d'une application donnée. L'utilisateur peut choisir un sujet et obtenir une information d'aide sur ce sujet. D'autres mécanismes permettent à l'utilisateur d'obtenir un message d'aide sur un sujet ou sur un objet, limité à une ou deux lignes. Le pointage d'un objet avec la souris (ou avec le dispositif de pointage) constitue une façon agréable d'accéder à une rubrique d'aide ou à un message d'aide associé à l'objet. On parlera dans ce cas d'aide contextuelle. L'aide contextuelle est particulièrement utile lorsqu'il s'agit du premier contact de l'utilisateur avec l'application. Pour accéder à l'aide contextuelle, I'utilisateur doit mettre en oeuvre une touche ou une combinaison de touches prédéterminées, comme par exemple la touche Fl ou la combinaison de touches Ctrl Fl, lorsque le dispositif de pointage sur l'écran survole un objet particulier ou lorsque cet objet a le focus. Le système d'aide fournit alors un texte informatif qu'il trouve dans un fichier regroupant les textes d'aide associés à une application donnée. La création du texte d'aide et son association avec un programme donné est une opération effectuée lors du développement de l'application préalablement à son utilisation. Le développement du texte d'aide et l'association du texte d'aide avec les objets est une procédure délicate. Un des inconvénients majeurs des actuels systèmes de développement d'aide réside dans le fait que le développeur de l'aide doit avoir accès au code source de l'application à documenter pour associer l'aide aux différents objets de l'application. Cela signifie que le développeur de l'aide doit travailler avec le développeur de l'application pour mettre en place les liens entre les objets de l'application et les textes d'aide associés. Il est difficile d'organiser le développement de l'aide alors que l'application est elle-même en cours de développement. Il est par ailleurs impossible de développer de l'aide pour une application existante dans la mesure où celle-ci est réalisée par un développeur tiers et n'est livrée que sous forme de code exécutable, et en tous cas sans code source. C'est pourquoi le développeur d'aide ne peut pas créer une nouvelle aide ou adapter une aide existante concernant une application existante. La figure 1 montre le système d'aide originel et habituel de l'environnement Windows. Dans la figure 1, le code source 10 constitue le point de départ à partir duquel il est possible d'associer des numéros de contexte aux objets de l'application. A chaque application spécifique correspond un code source dont l'application provient directement. Certaines instructions de l'application source. comme l'instruction 22 sont des appels de fonction de l'environnement Microsoft Windows. L'exécution d'une application Microsoft Windows est symboliquement représentée en 16 dans la figure 1. Un exemple de tels appels de fonction : "WinHelp (... Context &num; ...)" représenté en 22. En pratique, I'étiquette "Context &num;" est remplacé par une valeur, ou une constante qui correspond à une rubrique du fichier d'aide 20. Le code source de l'application 10 est compilé (compilateur 12) afin de produire une application exécutable 14, exécutée par l'environnement Windows 16. L'environnement Windows 16 reconnaît les demandes de l'utilisateur qui conduiront aux appels à WinHelp. Un message concernant la demande de l'utilisateur est transmis au moteur de surveillance (30 dans la figure 2.) qui provoque un appel au moteur d'aide Windows (18). Le moteur d'aide 18 accède au fichier d'aide 20 afin d'afficher sur l'écran le texte d'aide qui correspond à l'objet ou au sujet désigné par le numéro de contexte. De plus amples informations concernant la technique originelle de développement d'aide se trouvent dans "Borland C++ Tools and Utilities Guide", version 3.1", chapitre 7, par Borland International Inc. 1992. Une description de l'interface utilisateur des systèmes de développement d'aide se trouvent aussi dans les manuels des outils de DDTEC SA (Help Maker - 1992 - et WYSI-Help - 1994 -). Pour ce qui concerne les interfaces de programmation d'applications (API) de Microsoft Windows, il est utile de se reporter aux références suivantes "Programming Windows 3. 1" ou "Windows 3. 1 Software Development Kit" par Microsoft Press. Comme cela est indiqué ci-dessus, le procédé originel de développement de systèmes d'aide, tel que décrit dans la figure 1, ne permet pas au développeur d'aide de travailler sur le système d'aide sans avoir accès au code source de l'application pour laquelle le système d'aide est prévu. Cette restriction augmente les coûts et les délais du développement d'un bon système d'aide et empêche d'ajouter un système d'aide à une application existante si on en n'est pas le développeur ou si on ne peut accéder aux sources. La présente invention permet d'intervenir sur des programmes existants en vue d'enrichir ces programmes par ajout de fonctionnalités sans qu'il ne soit besoin d'avoir accès au code source de ces programmes, de modifier, de recompiler ou encore de décompiler (reverse engineering) ces programmes. Dans un environnement graphique, un programme se présente à l'utilisateur sous forme d'objets graphiques dessinés à l'écran qui constituent l'interface de l'applicatif. L'utilisateur agit sur les objets de l'interface (avec la souris ou avec le clavier) pour piloter l'application. La présente invention repose sur un procédé d'identification unique des objets constituant l'interface d'un programme applicatif, de surveillance des actions effectuées par l'utilisateu sur ces objets et de déclenchement d'actions non prévues dans le programme applicatif originel. Une application exemple de la présente invention permet ainsi de séparer les tâches de développement d'une application de celles de développement de l'aide contextuelle associée à l'application. L'invention intercepte les messages et les appels de fonction du système d'exploitation et permet d'utiliser un système d'aide avec une application exécutable sans avoir besoin de recompiler l'application ni de modifier son code source. La présente invention autorise l'accès à des systèmes d'aide plus riches que du texte seul, en ce sens qu'il est possible de surveiller des programmes applicatifs depuis le système d'aide. Le système d'aide résultant de la présente invention permet aussi de déclencher des programmes externes depuis le système d'aide afin d'aider l'utilisateur à comprendre ou même à effectuer l'opération qui l'intéresse. Dans une application exemple de l'invention, une méthode permet d'implémenter de l'aide contextuelle dans un système informatique sous contrôle d'un utilisateur. Le système informatique est constitué d'un processeur, d'une mémoire, de dispositifs d'acquisition (souris, clavier par exemple) et d'un écran. Le système informatique comprend en plus un système d'exploitation et un programme applicatif qui affiche des images à l'écran. Chaque image correspond à un objet identifié par: (1) le système d'exploitation. par un numéro d'identification (ID) qui permet d'obtenir les caractéristiques de l'objet, (2) I'application qui génère l'image de l'objet. Dans ce cas l'invention utilise d'autres moyens pour obtenir l'identification de l'objet, comme une technique de sous-classement ou d'analyse de signature décrites ci-dessous. L'image de l'objet peut être sélectionnée par l'utilisateur en utilisant le dispositif d'entrée d'une façon prédéterminée. Le système d'exploitation envoie un message à l'application pour l'informer de la sélection de l'objet. Ce message comprend les caractéristiques de l'objet. La mémoire du système informatique renferme une liste d'objets et leurs caractéristiques. Un objet donné de la liste est associé avec un texte d'aide donné. La méthode repose sur un certain nombre d'étapes effectuées par le processeur - interception du message entre le système d'exploitation et l'application, - détermination du fait que les caractéristiques de l'objet dans le message intercepté correspondent aux caractéristiques d'un objet dans la liste des caractéristiques stockées pour les objets surveillés, - enfin déclenchement de l'affichage du premier message d'aide sur l'écran. Il est à noter que dans cette application exemple l'affichage de l'aide ne constitue qu'un exemple de fonctionnalité supplémentaire que l'invention permet d'ajouter à un applicatif existant. L'affichage de l'aide résulte en fait du lancement d'un programme spécifique (moteur d'aide). De façon plus générale le procédé objet de l'invention permet d'associer le lancement de n'importe quel type de programme à un objet et permet donc de modifier des fonctionnalités ou d'ajouter des fonctionnalités à un applicatif existant. La figure 1 illustre le développement d'un système d'aide selon la méthode originelle. La figure 2 illustre le développement d'un système d'aide conformément à la présente invention. La figure 3 illustre le système informatique convenant à la mise en oeuvre de la présente invention; La figure 4 illustre les sous-systèmes de base du système illustré la figure 3. La figure 5 est un diagramme montrant les relations entre des agents d'une liste d'agents, des liens et des fichiers d'aide. La figure 6 montre une liste d'agents. La figure 7 est une organigramme d'une procédure de la présente invention qui teste la concordance d'objets par rapport à une liste d'agents. La figure 8 illustre les structures de données utilisées par la présente invention. La figure 9 est un organigramme plus détaillé concernant les phases de la reconnaissance d'un agent sélectionné par rapport à ceux qui figurent dans une liste d'agents. La figure 10 est un organigramme d'une procédure qui exécute un fichier script. La figure 11 est l'organigramme d'une procédure qui identifie un objet. La figure 12 un organigramme d'une procédure de description d'un objet. L'annexe A contient un code source correspondant à des procédures particulières qui implémentent le procédé selon l'invention. Le code source et les structures de données sont écrites dans le langage de programmation Turbo Pascal (Borland Inc) et pourront être consultés pour obtenir de plus amples détails spécifiques sur l'invention qui va être décrite. La figure 2 montre un diagramme de la figure 1 modifié pour refléter le mécanisme de développement d'aide issu de la présente invention. Comme le procédé inventé pour identifier les objets apparaissant à l'écran en analysant leurs caractéristiques est adaptable pour servir à d'autres applications, I'application exemple applique la méthode d'identification au développement d'un système d'aide en ligne dans l'environnement Windows. La description qui est faite concerne les détails du système de développement d'aide résultant de l'invention et l'application plus générale de l'invention pour intervenir au niveau d'applications fermées. Dans la figure 2, les traitements logiciels sont représentés par des cercles et des ovales, alors que les fichiers de données sont représentés par des rectangles. En général, I'utilisation du même numéro de référence dans plusieurs figures désigne la même entité. Ainsi, la figure 2 montre une application 14 qui ne communique plus directement avec l'environnement Microsoft Windows 16. Le moteur de surveillance 30 de la figure 2 intercepte les messages et les appels système (qu'on désignera collectivement par le terme "communications") entre l'application 14 et Microsoft Windows 16. Dans les faits, le moteur de surveillance 30 laisse passer la plupart des messages sans les affecter. Cependant, quand le moteur de surveillance 30 détecte un message qui désigne un événement déclenchant une action (comme l'affichage d'un message d'aide), le moteur de surveillance 30 empêche Microsoft Windows 16 d'interpréter directement le message. A la place, le moteur de surveillance 30 détermine quel est l'objet de l'application 14 qui a le focus au moment de la demande d'aide. Ce faisant, le moteur de surveillance 30 détermine quelle image d'objet à l'écran est pointé par l'utilisateur, sélectionné ou activé et assume, pour apporter une aide contextuelle, que l'objet correspond à celui pour lequel l'utilisateur a besoin d'aide. Le moteur de surveillance 30 accède à la liste des agents 32 qui contient la description des objets et les événements associés. Chacun des agents peut inclure un lien vers une ressource d'aide 20. La liste des agents 32 contient une liste d'événements déclencheurs et est détaillé plus avant. Si l'objet qui a le focus fait partie de la liste des agents 32, le moteur de surveillance 30 envoie un message pour demander à ce que l'action correspondante à cet agent soit effectuée. Dans le cas d'une action d'aide, le nom de lien est passé au moteur d'aide de Windows 18. Le moteur d'aide de Windows 18 présente alors la rubrique appropriée à partir du fichier ressource de l'aide 20. De façon alternative, un message d'aide court peut être directement affiché par le moteur de surveillance dans la barre de titre de l'application, ou encore dans une bulle d'aide, etc. Plusieurs améliorations du système d'aide général sont discutées dans ce qui suit, après la présentation du matériel nécessaire au support des méthodes de la présente invention. La figure 3 est l'illustration du système informatique support de la présente invention. La figure 3 décrit l'un des exemples de configuration possibles. II s'agit d'un système informatique 37 comprenant - un moniteur 38, incluant un écran d'affichage 31. - un boîtier 33, - un clavier 36 et une souris 35. La souris 35 et le boîtier 36 sont des dispositifs d'entrée d'informations pour l'utilisateur. D'autres exemples de dispositifs d'entrée : un écran tactile. un "light pen", un "track-ball", etc. La souris 35 peut avoir un ou plusieurs boutons, comme ceux 34 de la figure 3. Le boîtier 33 héberge les composants habituels, à savoir des unités de disquettes, un processeur, des moyens de stockage (qui incluent tous les dispositifs de stockage utilisés dans-un système informatique comme des unités de disquettes, des disques durs, des lecteurs de bandes magnétiques, des mémoires à bulle, des lecteurs de CD-ROM, des mémoires non volatiles, etc.). Le boîtier comprend des dispositifs matériels additionnels comme des cartes interface d'entrée/sortie pour connecter le système informatique à des dispositifs externes, comme des unités de stockage externes, des modems, des imprimantes, d'autres ordinateurs, etc. La figure 4 illustre les sous-systèmes de base dans un système informatique 37 de la figure 3. Dans la figure 4, les sous-systèmes sont présentés par blocs comme le processeur central 40, la mémoire du système 42, le contrôleur d'écran 44, le moniteur 46, etc. Les sous-systèmes sont interconnectés par un bus 48. D'autres sous-systèmes comme une imprimante, un clavier une disque dur et d'autres encore sont montrés. Les périphériques et les dispositifs d'entrée/sortie peuvent être connectés au système informatique par exemple via un port série 50. Le port série 50 peut par exemple être mis en oeuvre pour connecter le système informatique à un modem. L'interconnexion par l'intermédiaire d'un bus 48 permet au processeur de communiquer avec chaque sous système et de contrôler l'exécution des instructions à partir de la mémoire 42 ou du disque dur 52, ainsi que l'échange entre les différents sous-systèmes. D'autres organisations des sous-systèmes et de leurs interconnexions est possible. La figure 5 illustre une liste d'agents 32 et les fichiers d'aide 20 de la figure 2. La figure 5 montre aussi les liens, comme le lien 116, associé à l'un des agents de la liste 32. Chaque agent porte un nom d'agent, représenté par le symbole "nom-d'agent" 100. Les liens sont symboliquement présentés à la droite de la liste des agents 32, en 102,. Les petits cercles sans flèche adjacente en émanant sont des noms d'agent sans lien associé. A titre d'exemple, le premier agent de la liste 32 porte un lien vers le contenu d'aide 106. Un contenu d'aide comme le 106 inclut le texte d'un message d'aide court et d'une rubrique d'aide. Un message d'aide court est constitué d'une ou deux lignes apparaissant dans un endroit de l'écran et qui ne nuit pas à la lisibilité de l'application pendant que l'utilisateur met en oeuvre l'application. L'aide courte sert à donner une brève description de l'objet qui a le focus ou qui est survolé par le curseur de la souris à l'instant donné. La rubrique d'aide est constituée de messages d'aide textuels, graphiques ou multimédia plus volumineux et permet à l'utilisateur de pénétrer dans un réseau d'informations textuelles, désigné sous le nom d'hypertexte, afin de fournir une information d'aide plus substantielle à l'utilisateur. Il y a en fait, en interne, des agents séparés pour chaque rubrique et chaque message d'aide. Les agents respectifs ont le même nom de lien mais des événements déclenchant différents. Le texte d'aide 106 renvoie vers un mécanisme d'aide additionnel 112, prévu pour implémenter des fonctionnalités différentes comme des menus pop up, des liens hypertexte, etc. Le second nom d'agent de la liste des agents 32 est relié au texte d'aide 110. Le troisième nom d'agent est relié à une application externe 114. Le lien vers une application externe (comme 114) présente la capacité de la présente invention à envoyer des messages ou à exécuter des fonctions en réponse à une demande d'aide de l'utilisateur. Le quatrième nom d'agent de la liste 32 est relié au texte d'aide 104, alors que le cinquième nom d'agent est relié au texte d'aide 108 et ainsi de suite. Les liens, représentés par des flèches émanant de la liste des agents 32 sont implémentés par le moteur de surveillance 30, Microsoft Windows 16. le moteur d'aide de Microsoft 18, figure 2. La figure 6 montre une liste d'agents, tels qu'ils apparaissent dans un produit dénommé WYSI-Help (anciennement Help Maker) de DDTEC SA. La liste d'agents de la figure 6 est facile à créer en une utilisant une technique de capture d'objets de type "pointer et cliquer", technique décrite dans le manuel de référence de Help Maker version I publié par DDTEC SA en 1992. Dans l'application exemple, chaque "agent" inclut un événement, un objet et une action. Un événement, comme un clic souris sur un objet (un menu par exemple). produit une action. comme l'apparition d'un texte d'aide sur l'écran. Un objet peut être affiché sur l'écran et possède des caractéristiques qui lui sont propres. Des exemples de caractéristiques d'un objet : son titre, sa classe, son ID, son style, ses objets parents, son nombre d'objets fils, sa taille, sa place et sa couleur à l'écran (x, y, z) et, en général toutes les caractéristiques de l'image qui en est perçue par l'utilisateur. La liste des agents est une liste avec une entrée pour chaque agent. Les agents correspondent à un objet sélectionné par l'utilisateur en s'appuyant sur l'une ou plusieurs des caractéristiques de l'objet qui correspond aux caractéristiques de l'objet agent. Comme cela apparaît sur la figure 6, la liste des agents de l'application exemple est organisée en deux parties principales, "Non linked objects" et "Existing Links". Sous le titre "Existing Links", deux liens apparaissent "New" et "Open". Le lien "New" est le nom d'un lien comme le lien 116 de la figure 5. En dessous du lien New, apparaissent une entrée pour l'aide courte (Short Help) ainsi que pour le texte d'aide (Topic Help). L'aide courte et le texte (la rubrique) d'aide correspondent aux textes 106 de la figure 5. Pour le lien "New", l'aide courte correspond au texte "Edit a new document" alors que la rubrique d'aide correspond au texte "Creating a new file". L'item suivant de la liste au dessus du lien existant "New" est une caractéristique d'objet Menu:MenuItemClass 'New' 4097. Juste en dessous de cette caractéristique d'objet, il y en a une autre Applic:MSWRITE~MENU 'Write - [Untitled]'. Ces deux caractéristiques d'un objet définissent la chaîne associée à l'objet (ou à une séquence d'objets) et correspondent à l'agent qui inclut l'objet. Ainsi, L'agent "New" est identifié (reconnu) par les caractéristiques d'objet 150 et 152. La présente invention permet de décrire un objet par les caractéristiques de tous ses parents, ainsi que par un nombre suffisant de ses caractéristiques propres, de façon à ce que l'objet soit unique vis à vis des autres objets, dans la liste des agents. Dans la figure 6, I'agent, incluant l'objet dont les caractéristiques sont décrites en 150 et 152 inclut le titre, la classe et l'ID de l'objet 150, le titre et la classe de l'objet 152. De façon similaire au lien "New", un second lien dénommé "Open..." est montré en 154. Pour le nom de lien 156, l'aide courte (chaîne vide) est en 158, et la rubrique est montrée par le message "Topic Editor not loaded" en 160. Un agent inclut ensuite toutes les caractéristiques des objets 162 et 164. Sous le titre "Non linked Objects" en 180 - figure 6, il y a quatre noms d'agents référencés 182, 184, 186 et 188. Un exemple d'objet d'agent non relié est le sixième agent dans la liste d'agents 32 de la figure 5. Ainsi, les agents peuvent figurer dans la liste des agents sans avoir été reliés à un texte d'aide ou à une action d'aide. Les agents 182, 184 et 188 incluent chacun les caractéristiques de deux objets alors que l'agent 186 n'inclut les caractéristiques que d'un seul objet. La chaine des objets d'un agent comprend tous les objets parents et un nombre variable des caractéristiques de chaque objet, en fonction du détail nécessaire pour distinguer l'objet de façon unique comme décrit ci-dessous. La figure 7 décrit l'organigramme d'une procédure de la présente invention qui teste la concordance d'objets dans une liste d'agents. En général, les organigrammes présentés dans ces spécifications illustrent une ou plusieurs procédures logicielles qui s'exécutent dans un système informatique comme 37 figure 3. Les procédures peuvent être implémentées par un moyen quelconque correspondant à l'état de l'art. II est par exemple possible d'utiliser un ou plusieurs des langages de programmation parmi lesquels : "C", Pascal, Fortran, Assembleur, etc. De plus, plusieurs techniques de programmation sont possibles : procédurale, orientée objet, recourant à de l'intelligence artificielle, etc. Les étapes présentées dans les organigrammes peuvent être implémentées en une ou plusieurs procédures, process. fonctions, modules. etc. Il doit être clair que chaque organigramme illustre tout simplement le flux logique du procédé de la présente invention, et que des étapes peuvent être ajoutées ou soustraites des organigrammes sans sortir de l'épure de l'invention. de même que l'ordre d'exécution des étapes de l'invention, sans pour autant en changer le fond. Des considérations additionnelles dans l'implémentation du procédé. par rapport à ce qui est décrit par les organigrammes peuvent provoquer des changements dans la sélection et l'ordre des étapes. Certaines considérations reposent sur l'orientation événementielle, sur le mécanisme d'interruption, de surveillance et autres schémas. Des environnements multiprocesseurs ou multitâches peuvent permettre une exécution "concurrente" de certaines tâches. Par simplification de l'exposé, l'implémentation de chaque organigramme est décrite comme s'il s'agissait d'une procédure unique. Dans la figure 7, la procédure correspondant à l'organigramme 200 commence à l'étape 202. A ce niveau d'entrée, il est supposé que l'utilisateur a sélectionné un objet et a demandé de l'aide contextuelle pour cet objet. Dans l'application exemple, I'utilisateur sélectionne un objet en déplaçant le pointeur du dispositif de désignation au dessus de l'image de l'objet présentée à l'écran et demande de l'aide en activant une touche ou une combinaison de touches comme FI ou Ctrl-FI. Quant l'utilisateur presse sur la touche ou sur la combinaison, l'image de l'objet qui a le focus est détectée par le système d'exploitation qui envoie des messages aux applications. La procédure correspondant à l'organigramme 200 est implémentée par une tâche appelée le "moteur de surveillance" dans le système WYSI-Help (anciennement Help Maker). Le moteur de surveillance comporte dans son code la fonction MyKeyHook, incluse dans le code source fourni en annexe de la présente spécification. Les autres messages et événements, dans l'environnement Windows, sont interceptés aux moyen des procédures MyGetHook et MySndHook. Dès son début, la procédure de l'organigramme 200 est alimentée par de l'information concernant la sélection qui est intervenue, comme l'objet qui a le focus, la nature de l'événement, et la tâche à partir de laquelle l'événement est intervenu. A l'étape 204 un contrôle est opéré afin de détecter si l'objet sélectionné appartient à l'une des applications surveillées par le moteur de surveillance. Cette étape correspond à la fonction checkEvent dans le code source annexé. La raison de ce test 204, dès cette étape de la procédure permet d'éliminer rapidement les objets et les événements de la suite de la procédure s'ils ne correspondent pas à la tâche pour laquelle l'aide existe. Si la tâche n'est pas dans la liste, l'exécution se termine par l'étape 214. Cependant, si la tâche est dans la liste, I'exécution se poursuit par l'étape 206, où l'on contrôle si l'objet appartient à un agent dans une liste d'agents. Si l'on suppose que cela est vrai, on passe à l'étape 208. Dans l'application exemple, une liste d'agents est entretenue par le moteur de surveillance pour chaque événement spécifique. Un agent est une entité qui inclut un événement, une chaîne d'objets et une action. La liste des agents est simplement la liste des agents que l'application exemple compare aux actions de l'utilisateur (c'est-à-dire un événement ou une action) pour leur faire correspondre par exemple un texte d'aide via un nom de lien. Avant de procéder à l'exposé de la figure 7, il est nécessaire de procéder à quelques définitions concernant les structures de données de base de l'invention. Dans un environnement fenêtré. un objet sélectionné donné peut avoir des parents et des fils, de sorte que l'objet appartient à une hiérarchie, selon laquelle l'objet n'est pas accessible si ses parents n'ont pas été sélectionnés ou activés. En corollaire, les fils d'un objet donné ne peuvent pas être accédés et sélectionnés tant que l'objet lui même n'aura pas été sélectionné ou activé. Quand le procédé de la présente invention a besoin d'identifier ou de décrire, de manière unique, un objet sélectionné, il s'appuie sur le handle de l'objet sélectionné et obtient les caractéristiques de l'objet en invoquant des procédures du système d'exploitation ou de l'environnement fenêtré. Le handle d'un objet est un numéro (ou un identificateur) qui lui est donné par le système d'exploitation lors de sa création de l'objet, ce numéro servant par la suite pour accéder à l'objet. Si un nombre suffisant des caractéristiques ne peuvent être obtenues, l'invention utilise des techniques de sous-classement ou de subdivision, détaillées ci-après pour identifier l'objet. L'invention obtient les caractéristiques permettant d'identifier un objet simple de façon unique et continue ainsi la description de chacun des objets simples de la hiérarchie des objets, en obtenant d'abord le handle des objets, puis via le handle les caractéristiques. Les objets ainsi décrits sont reliés entre eux pour obtenir une "chaîne objet" pour l'objet sélectionné. L'objet sélectionné, lui-même, est inclus dans cette chaîne. Au minimum, la chaîne sera simplement constituée de l'objet sélectionné et de ses caractéristiques. Tout au long de ces spécifications, le terme "objet" est souvent utilisé pour indiquer à la fois l'objet sélectionné et la chaîne objet, qui outre l'objet sélectionné comporte les parents de l'objet sélectionné. Quand il est nécessaire de parler d'un objet unique, partie de la chaîne objet, le terme "objet simple" est employé. "objet" et "objet simple" ne font qu'un quand l'objet n'a pas de parents. La figure 8 illustre la structure de données de base pour les agents et les objets. L'agent 1 est montré avec tous les items de la boîte 220. Ainsi, l'agent 1 comprend l'événement 222, "événement de déplacement de la souris", une chaîne objet 223 qui comprend l'objet 224 et ses parents objet 226, action 228, "Short Help 'New'." L'agent 2 est représenté par la boîte 230, et inclut l'événement 232, "évènement clavier", la chaîne objet 234 (la même chaîne objet que la chaîne objet 223) et l'action 236, "Rubrique d'aide New". Les objets des chaînes 223 et 234 ont les caractéristiques des objets 224 et 236. L'objet 224 a une caractéristique classe "MenuItemClass". L'objet 224 a aussi une caractéristique Titre "New" et une caractéristique ID "4097". Une ou plusieurs de ces caractéristiques peuvent être utilisées pour aider à identifier de façon unique l'objet 224. Des caractéristiques complémentaires peuvent aussi être utilisées. L'objet 226 a une classe "Applic:MS~WRITE" et un titre "Write - [untitled]". La flèche qui relie l'objet 224 et l'objet 226 montre que l'objet 226 est le père de l'objet 224. Cela signifie aussi que l'objet 224 est l'objet fils de l'objet 226. Cette relation se reflète dans les caractéristiques telles que le nombre des objets fils ou le nombre des objets parents de chaque objet, bien que ces caractéristiques ne soient pas illustrées pour les objets 224 et 228 dans la figure 8. Les agents tels que le I et le 2 appartiennent à la liste des agents. Leurs chaînes objets peuvent être recherchées et comparées afin d'identifier si l'utilisateur a sélectionné un objet qui a été prévu comme contexte d'aide par le développeur du système d'aide. En retournant à l'organigramme de la figure 7 et à l'étape 208, les caractéristiques de l'objet sélectionné par l'utilisateur sont obtenues. Ensuite, il s'agit de l'étape 210, L'objet sélectionné est comparé à ceux des agents de la liste des agents. Comme cela a été mentionné plus haut, le moteur de surveillance entretient une liste d'agents pour chaque type d'événements spécifiques, de sorte que la recherche des agents dans les listes se limite à la liste des agents correspondant à l'événement particulier. Afin de faciliter l'exposé, les listes d'agents collectives sont ici considérées comme une simple liste d'agents. Les listes d'agents peuvent être communes à plusieurs applications et une seule application peut posséder plusieurs listes d'agents qui lui sont attachées. Si le couple objet+événement ne se trouve pas dans la liste. l'exécution s'achève à l'étape 214. Si, au contraire, le couple figure dans la liste des agents I'exécution se poursuit à l'étape 212, où une action d'aide intervient, conformément au lien attaché à l'agent reconnu. Dans l'application exemple, un texte d'aide est affiché soit sous forme d'un court message, soit par l'intermédiaire d'une rubrique. De plus des liens hypertexte ou popup sont possibles, tout comme le chargement ou l'exécution d'une application externe en réponse à la demande d'aide de l'utilisateur par rapport à l'image de l'objet à l'écran. Les actions complémentaires détaillées dans ce qui suit concernent le contrôle ou l'inhibition d'un programme par le moteur de surveillance par substitution de messages "null" pour inhiber l'action, et par le contrôle d'une application par génération de messages pour demander des opérations à l'application. On parlera dans ce cas de robotisation de l'application. Après que l'action d'aide soit intervenue à l'étape 212, la procédure de l'organigramme 200 s'achève en 214. Ainsi, la figure 7 montre les principales étapes logiques de haut niveau utilisées dans la présente invention au seul but de reconnaître si un événement associé à un objet sont présents dans une liste d'agents prédéfinis. Ensuite, la figure 9 montre plus en détail les étapes de reconnaissance d'un couple événement + objet par rapport à un agent d'une liste d'agents. La figure 9 montre un organigramme 240 qui est une extension de deux étapes montrées dans la figure 7. L'étape 212 est commune aux figures 7 et 8 et les étapes restantes en figure 9 correspondent à l'étape 210 de la figure 7. Ceci dit, les étapes 242-270 de la figure 9 déterminent si une combinaison objet + événement est dans une liste d'agents de la même manière que l'étape 210 de la figure 7. Dans la figure 9, la procédure de l'organigramme 240 démarre à l'étape 242 après que l'étape 208 de la figure 7 ait été exécutée. L'objet sélectionné par l'utilisateur a été déterminé et ses caractéristiques obtenues. Comme indiqué plus haut, un agent peut comprendre un ou plusieurs objets. Chaque objet peut avoir des caractéristiques multiples. Dans l'application exemple, les caractéristiques du titre, de la classe et de l'ID sont principalement utilisées. D'autres caractéristiques comme le style, L'ordre de l'objet (Z order), le nombre de fils et le contenu des fils peuvent être utilisés, si besoin, pour identifier de façon unique un objet d'agent. Dans le présent exemple, L'objet sélectionné possède une chaîne objet qui comporte les objets parents. La variable "check~obj" est utilisée pour spécifier les objets simples de la chaîne d'objets. Les objets simples de la chaîne d'objets des agents sont repérés par la variable "current~obj". A l'étape 244, current~obj est porté à une valeur qui correspond au premier objet simple du premier agent de la liste. A l'étape 246 check~obj correspond au premier objet simple de la chaîne objet sélectionnée. Les étapes 246-268 forment une boucle testant les caractéristiques des chaînes d'objet de chaque agent de la liste des agents par rapport aux caractéristiques des objets de la chaîne d'objets de l'objet sélectionné par l'utilisateur. La comparaison commence à l'étape 248 où un test est effectué afin de se demander si le titre de l'objet peut être utilisé dans une comparaison qui a pour but de comparer la chaîne d'objet de l'objet sélectionné avec une chaîne d'objets dans la liste d'agents. Si la comparaison aboutit, l'exécution se poursuit en 250 où les titres de current~obj et checkobj sont comparés. Si les titres correspondent, l'exécution se poursuit en 252, faute de quoi on saute à 264 tant que les chaînes d'objets ne correspondent pas. Supposant que les titres soient vérifiés et qu'ils correspondent, l'exécution se poursuit en 252, où il est procédé à un test pour examiner si les caractéristiques de la classe de current~obj et de check~obj doivent être testées. Dans l'application exemple, la détermination des caractéristiques à tester dépend d'une variable incluse dans current~obj. Les seules caractéristiques testées sont celles spécifiées par current~obj. L'exécution peut aussi atteindre l'étape 252 où les titres des objets ne sont pas l'un des critères de comparaison. Dans l'application exemple une variable "hmType" est utilisée pour indiquer les caractéristiques à tester. Dans cette application exemple I'utilisateur (développeur d'aide) peut indiquer quelles sont les caractéristiques à contrôler, celles-ci pouvant varier d'un agent à l'autre. En 252, I'exécution branche sur l'étape 256 si les caractéristiques de classe ne sont pas concordantes, ou à l'étape 254 dans le cas contraire. Comme précédemment. si les caractéristiques vérifiées et ne correspondent pas, current~obj ne convient pas et l'exécution passe en 264 où l'agent suivant de la liste est pris, afin que la boucle de test des caractéristiques de check~obj par rapport à celles du nouveau current~obj soit effectuée. L'étape 264 détermine s'il reste des agent dans la liste des agents. Dans le cas contraire, l'exécution de la procédure de l'organigramme 240 se termine en 270, sans qu'il y ait d'aide. S'il reste des agents dans la liste des agents, L'étape 262 est effectuée, afin d'affecter la variable current~obj avec le premier objet de la chaîne d'objets du prochain agent et la boucle qui commence à l'étape 246 est réexécutée. Au retour dans la boucle qui teste les caractéristiques, L'étape 256 effectue un test pour examiner si la caractéristique ID doit constituer l'un des critères de comparaison agent/objet par rapport à la liste d'agents. Si tel est le cas. l'exécution progresse en 258 où les Ids sont comparés. Dans le cas contraire I'exécution passe en 260 où il est testé les autres objets de la chaîne d'objets de l'agent courant. L'agent courant est l'agent qui dans la liste d'agents. subit les comparaisons. S'il n'y a plus d'objet simples dans l'agent courant. et qu'il n'y a plus d'objet simple dans la chaîne d'objets sélectionnée, alors une concordance a été mise en évidence et l'action 212 est entreprise. Dans le cas contraire, I'exécution se poursuit en 268. En 268, il n'y a plus d'objets simples dans l'agent courant ou il n'y a plus d'objet dans la chaîne d'objets sélectionnée, alors que les longueurs des chaînes d'objets diffèrent, ce qui fait qu'il ne peut plus y avoir concordance. On passe alors à l'étape 264 afin d'obtenir l'agent suivant dans la liste. S'il y a encore des objets à tester à la fois dans l'agent courant et dans l'objet sélectionné, l'exécution se poursuit en 266. Actuellement, l'application exemple dispose d'un agent par défaut afin de récupérer toutes les comparaisons d'agent/objet qui ne correspondent pas à d'autres agents dans la liste. L'agent par défaut peut conduire à des actions. comme d'indiquer par un message qu'il n'existe pas d'aide pour l'objet sélectionné. L'agent par défaut peut aussi permettre au système de rechercher un autre agent qui satisfasse à la requête d'aide. Cela revient à appeler CheckEvent comme si l'utilisateur avait sélectionné l'objet parent. En final, la procédure de la figure 9 se termine en ayant produit de l'aide en rapport avec la liste d'agents ou si celle-ci est épuisée en rapport avec l'agent par défaut. Ainsi, l'organigramme 240 de la figure 9 décrit une méthode de test des caractéristiques des objets par l'intermédiaire d'une chaîne d'objets avec les caractéristiques de chaînes d'objets d'une liste d'agents prédéfinis afin de trouver une concordance de l'objet sélectionné avec un agent de la liste. Une fois qu'il y a concordance, L'action correspondant à l'agent concordant de la liste est effectuée. Dans le cas d'une action d'aide, le nom de lien sert à trouver le texte d'aide approprié. Caractéristique de la signature Comme indiqué précédemment, il existe des caractéristiques standard comme le Titre, la classe, l'lD, le Style et l'ordre (Z order). Les autres caractéristiques comme le nombre de fils, leurs contenus et la Signature sont uniques dans le cas de l'application exemple de l'invention. Le nombre de fils d'un objet donné correspond au nombre d'objets fils appartenant à l'objet donné. Ce nombre peut être obtenu, pour un objet, par accès à une liste gérée en interne par l'environnement Windows. Le contenu du fils est une propriété d'un objet qui s'obtient par examen des caractéristiques de l'objet fils, dans le but de mieux identifier l'objet donné. Dans l'invention telle que présentée ci-dessus, un objet donné est identifié par les caractéristiques de ses objets parents. Ainsi les caractéristiques du contenu du fils constituent une autre approche possible pour identifier un objet. La caractéristique signature correspond à une liste de fonctions et de messages qui interviennent lorsqu'un message WM~Paint est envoyé à l'objet donné. Après avoir reçu le message WM~Paint, L'objet donné, c'est-à-dire l'objet qui reçoit le message se repeint lui-même, et se faisant appelle d'autres fonctions Windows et envoie ses propres messages. La combinaison des appels de fonction et de l'envoi des messages constitue la "signature" de l'objet en ceci que les appels de fonction et les envois de messages diffèrent d'un objet à l'autre. Ainsi la caractéristique signature peut être utilisée pour identifier un objet, particulièrement s'il est difficile d'identifier l'objet de façon unique en s'appuyant sur ses autres caractéristiques. Sous-classement Certains objets considérés comme tels par l'utilisateur ne sont pas considérés comme des objets par l'environnement Windows et de ce fait n'ont pas de "handle". Cela créé un problème pour un procédé comme celui de la présente invention car il n'est pas possible de demander à l'environnement Windows les caractéristiques de l'objet, et les objets de ce type ne peuvent pas être décrits comme cela a été démontré. Une solution consiste à sous-classer ces objets utilisateur qui ne sont pas des objets pour l'environnement Windows. Des exemples de ce type d'objets : choix de menu, items d'une liste, textes, bit-maps. Pour ces non-objets. les messages-clé et les fonctions sont surveillés de façon à donner à ces non-objets un contexte complémentaire qui permettra de ranger l'objet dans une catégorie standard. Par exemple, la sélection de chaque choix de menu est enregistrée, de façon à ce que lorsqu'une capture intervient, ce soit le choix qui soit reconnu et pas la fenêtre de menu. Et ce. malgré le fait que le choix de menu n'est pas un vrai objet, en ce sens qu'il ne possède pas de handle de fenêtre, ni de classe, etc. Une pseudo classe est attribuée à l'objet sous-classé (comme pour ses autres caractéristiques) et la fenêtre contenant le menu est utilisée comme parent. De façon grossière, le sous-classement consiste à créer un objet pour correspondre à une image sur l'écran (texte ou autre chose) quand cette image ne correspond pas à un objet reconnu de l'environnement Windows. Pour montrer comment l'application exemple effectue ce sous-classement, il est fait référence aux figures 11 et 12 qui décrivent les étapes de base de procédures qui apparaissent dans le code source annexé A. La figure 11 - organigramme 400 correspond à la procédure IdentifyObject de l'annexe A. Cette procédure appelle la procédure DescribeObject de la figure 12. Ces deux procédures, ainsi que les autres procédures et fonctions annexées en A implémentent les aspects généraux de la présente invention pour ce qui concerne l'identification des objets en s'appuyant sur leurs caractéristiques. Cependant, ces procédures sont détaillées pour illustrer spécifiquement le sous-classement. tel qu'effectué par l'application exemple. L'annexe A peut servir d'appui à l'exposé ci-dessous. Le point d'entrée de la procédure IdentifyObject se situe en 402 : un handle d'objet est passé comme paramètre de la procédure. La procédure IdentifyObject détermine toutes les caractéristiques de l'objet cible nécessaires pour identifier l'objet de façon unique par rapport aux autres objets de l'application hôte, incluant l'identification des parents de l'objet. Les parents de l'objet font partie de la chaîne d'objets de l'objet cible. A l'étape 404, L'objet cible est décrit par l'appel de la procédure DescribeObject qui effectue le sous-classement des non-objets au sens de l'environnement Windows. Elle le fait en interrogeant la procédure utilisée pour créer le non-objet, comme les fonctions spécifiques de l'application, les messages de menus, etc. La procédure détermine si quelque chose a été sous-classé. La procédure DescribeObject positionne aussi les caractéristiques de l'objet et de tous les objets parents dans la chaîne de l'objet. Une fois que l'objet cible a été décrit, L'étape 406 est exécutée, afin de trouver des caractéristiques supplémentaires de l'objet, si besoin. En regardant le code source de la procédure IdentifyObject en annexe A, les caractéristiques additionnelles peuvent être la surface de la fenêtre (si l'objet est une fenêtre), I'état d'un objet et le type d'un objet (si l'objet n'est pas un objet sous-classé). Ensuite, l'étape 408 détermine s'il y a d'autres objets dans la chaîne d'objets. Dans ce cas, L'étape 406 est ré-exécutée pour les objets complémentaires de la chaîne, jusqu'à ce que tous les objets de la chaîne se soient vus attribuer des caractéristiques, comme il le fallait. L'étape 410 est alors exécutée pour décrire le type de l'objet, par renseignement des champs hmType, et Typedesc. Le champ hmType a pour but de permettre d'établir le critère de comparaison de l'objet, comme discuté en figure 9. La valeur du champ hmType peut être modifiée ultérieurement par l'utilisateur de l'application exemple. Le champ Typedesc sert à indiquer, de façon générale, le type d'un objet. L'étape 412 est similaire à l'étape 408, en ce sens qu'elle assure l'application de l'étape 410 à tous les objets de la chaîne. Après que tous les objets de la chaîne aient été passés en revue, la procédure IdentifyObject se termine en 414. La figure 12 montre un organigramme 440 pour la procédure IdentifyObject de la figure 11. La procédure identifyobjet commence à l'étape 442, la procédure recevant le handle de l'objet. A l'étape 444, la procédure vérifie si la valeur du handle de l'objet est 0, ce qui signifie que l'objet est un choix de menu. Si l'objet est un choix de menu, il est marqué comme tel en 454 et l'exécution s'achève en 452. Si le handle n'est pas 0, on passe en 446. En 446, un test est effectué pour savoir si l'objet possède une zone de liste. Les zones de liste sont utilisées dans la présente invention pour traiter le cas, par exemple, des boîtes de dialogue dont un ou plusieurs contrôles sont des zones de texte et non des objets. Lorsque le programme applicatif est en mesure de détecter que l'utilisateur sélectionne un zone de texte, comme le texte "OK", I'environnement Windows ne considérera pas la zone de texte comme un objet et ne préviendra pas le moteur de surveillance des événements intervenant sur le texte, comme dans le cas d'un objet Windows "valide". Pour contourner ce problème, la présente invention inclut des "hooks" sur l'environnement Windows, de façon à ce que les messages en provenance / à destination de la boîte de dialogue soient interceptés par le moteur de surveillance. En gardant trace du texte et de ses positions par rapport aux objets comme les boîtes de dialogue, la présente invention permet de sousclasser le texte comme un objet. Les zones de liste peuvent être toutes les images affichées sur l'écran, mais non reconnues comme des objets par l'environnement Windows. Pour qu'une fenêtre dispose d'une zone de liste, elle doit d'abord être identifiée. Le champ hmType de la fenêtre contient de l'information permettant de savoir si la fenêtre renferme ou non des zones de liste. Dans un tel cas, la fenêtre est repeinte après avoir détourné les fonctions Windows telles que EXTEXTOUT et B1TBLT pour contrôler la repeinture, afin de détecter les sous-parties de la fenêtre. Tous les appels de fonction détournés sont examinés par rapport à la zone de l'écran où elles interviennent. Si la zone coïncide avec la position courante du curseur texte (s'il y en un) et la position est enregistrée. Le texte et la position seront utilisés ultérieurement par la procédure DescribeObject afin de définir la zone de liste. Les objets contenant des zones de liste gardent mémoire de leurs zones de liste en notant, lorsque les appels à l'environnement Windows sont effectués, les textes affichés dans les objets. Au moment de l'appel, L'objet et le texte sont enregistrés. Si l'objet possède une zone de liste qui a été enregistrée, I'exécution de l'organigramme 440 de la figure 12 s'effectue jusqu'à l'étape 456 où l'objet est marqué comme une zone de liste, et la procédure se termine en 452. Si l'on suppose que l'objet n'a pas de zone de liste, les caractéristiques de base de l'objet sont obtenues à l'étape 448 pour tous les objets de la chaîne de l'objet cible. Quand il n'y a plus d'objets à identifier, l'exécution de la procédure s'achève en 452. Ainsi, I'exposé ci-dessus correspondant aux figures 11 et 12 démontre que l'application exemple implémente le sous-classement des objets. Cela permet à des non-objets, c'est-àdire à des entités apparaissant comme des images à l'écran mais que Windows ne traite pas comme des objets valides, d'être identifiés par sous-classement des non-objets en objets, en leur attribuant des propriétés comme caractéristiques de sous-classification choix de menu ou zone de liste. Svstèmes d'aide multiples pour une seule application Un problème se pose lorsque l'on essaie d'appliquer le système décrit ci-dessus quand de multiples instances d'une même application fonctionnent en même temps. Cela peut être le cas dans un environnement multitâche, comme par exemple dans les environnements fenêtrés actuels. Par exemple, un utilisateur a la possibilité de lancer deux instances d'un programme de traitement de textes comme Microsoft Write. La deuxième instance du traitement de textes ne traitera probablement pas le même fichier que la première. Si l'on souhaite avoir le même système d'aide pour les deux fichiers, aucun problème. Cependant dans bien des cas, on souhaite avoir une aide particulière pour chaque instance de l'application. A titre d'exemple, un système d'aide décrira comment travailler avec le type de document chargé dans la première instance, alors que lorsqu'un document différent est chargé, une aide différente est requise. cela peut rester le cas même si les deux instances ne sont pas chargées simultanément. Une façon de traiter ce problème réside dans le fait de charger le programme par le moteur de surveillance de la présente invention. Le traitement de textes spécifie le document à charger. Comme le traitement de texte est chargé par le moteur de surveillance, il est possible de détecter le handle de toute fenêtre principale créée, et les tâches correspondantes sont ajoutées à la liste des tâches utilisées dans le test de l'étape 204 - figure 7. Il est ainsi possible d'avoir un système d'aide différent pour chaque type de document. Une solution alternative consiste à distinguer les différentes instances de l'application (le traitement de textes) à partir de leur barre de titre, en reposant sur le fait que la barre de titre contient le nom du document traité. Par exemple, deux instances de Write pourraient avoir les barres de titre suivantes : "Write - Ventes.WRI" et "Write - Couts.WRI" ce qui signifie que la première instance concerne l'édition d'un document de nom Ventes.WRI alors que la seconde instance édite un document Couts.WRI. De cette façon. I'application exemple distingue deux objets différents "Write Ventes.WRI" et "Write - Couts.WRI" en fonction du document chargé. En fait, comme tous les objets de l'application sont les descendants de la fenêtre principale, l'effet produit est de doubler le nombre d'objets qui peuvent être capturés. Cela permet de créer un système d'aide séparé pour chacun des documents. Il faut aussi remarquer que la présente invention peut aussi facilement permettre qu'il n'y ait qu'un seul système d'aide pour deux applications différentes. Cela est possible simplement en ayant une seule liste d'agents qui comprend les agents ayant des objets provenant de plus d'une tâche. Il faut conserver suffisamment de caractéristiques pour chaque objet aux fins d'identifier que les objets appartiennent à des tâches différentes. Cependant, si la même action doit être associée à des événements similaires pour des objets similaires entre les tâches, alors un même agent peut être commun à deux tâches ou davantage. Modification des fonctionnalités d'un programme existant Une des puissantes possibilités résultant de la présente invention est la capacité à modifier une fonctionnalité, ou à ajouter une fonctionnalité à une application existante. Le développeur n'a pas besoin d'accéder au code source de l'application. La fonctionnalité ajoutée peut être déclenchée par la sélection ou l'activation par l'utilisateur d'un ou de plusieurs objets affichés à l'écran, ou peut être déclenchée par un événement quelconque associé aux objets. L'environnement Windows demande l'exécution des tâches au fur et à mesure de l'intervention des événements au niveau de l'interface fenêtrée des applications. En détectant les messages déclenchants, en empêchant les messages conséquents de parvenir à l'application concernée et en envoyant des messages de contrôle aux objets sans l'intervention de l'application hôte, la modification ou l'ajout fonctionnel à une application sont atteints. Dans l'application exemple les messages sont interceptés et empêchés d'atteindre l'application hôte en les remplaçant par des messages "null". Le message n'a ainsi plus d'effet sur l'application hôte. Comme pour le système d'aide. I'identification unique des objets, basée sur les caractéristiques d'un objet est la clef de l'ajout ou de la modification de fonctionnalités d'une application existante sans avoir besoin de modifier ou de recompiler le code source de l'application. La présente invention peut ainsi contrôler une application par l'intermédiaire d'un fichier "script" qui indique des actions à effectuer sur les objets de l'application cible, ou même sur d'autres application. De plus, en complément de l'indication des actions, le fichier script utilise des commandes de synchronisation pour attendre qu'un événement intervienne sur un objet spécifié. La table 11, ci-dessous. montre un exemple d'un fichier script contenant six entrées. Le fichier script inclut des mots-clés qui peuvent être des actions ou des synchronisations. Le nom de lien est un pointeur vers un objet simple ou vers une chaîne d'objets plus un événement associé à l'objet ou à la chaîne d'objets. Chaque entrée du fichier script consiste en un mot clé et en un nom de lien. Les noms de liens qui correspondent à des synchronisations comprennent toujours un événement en plus du pointeur vers l'objet simple ou la chaîne d'objets. Mot-clé Nom de lien DoubleClic La petite icône 2 Clic Ouvrir Fichier 3 SYNC La boîte de dialogue + Ouverture 4 Clic Le bouton OK 5 SYNC La boîte de dialogue + Fermeture 6 Fermer La fenêtre principale Table II Dans le fichier script de la table H, la première entrée a un mot-clé "Double-clic", qui est une action, et un nom de lien "La petite icône" associée à ce mot-clé. La seconde entrée a un mot-clé qui est une action "Clic" et le nom de lien "Ouvrir Fichier". La troisième entrée dans le fichier script est un mot-clé SYNC associé à un nom de lien incluant "La boîte de dialogue" plus "Ouverture". La quatrième entrée dans le fichier script de la table H inclut l'action "Clic" sur l'objet "Le bouton OK". La cinquième entrée est un mot-clé SYNC sur l'objet "La boîte de dialogue" et l'événement "Fermeture". Enfin, la dernière entrée est l'action "Fermer" et concerne l'objet "La fenêtre principale". Lorsque le mot-clé est une action comme "Double-clic", "SYNC", "Clic" ou "Fermer", le fichier de script produit une action qui doit être effectuée sur l'objet référencé par le pointeur dans le nom de lien associé à l'action du mot-clé. Ainsi, la première entrée dans le fichier script est un double-clic sur une icône identifiée par le nom de lien "La petite icône". Les noms de lien de cet exemple son Dans le but d'identifier de manière unique l'objet pointé par le nom de lien "La petite icône", la liste entière d'ordre (Z order) du gestionnaire interne de Windows est contrôlée. La liste d'ordre est actuellement une liste de handles. Un handle est obtenu à partir de la liste et sert lui-même à obtenir les caractéristiques. Cette opération passe par les commandes de Windows GetNextWindow. GetWindow et EnumChildWindows de façon à balayer les objets de la liste Z order et obtenir leurs caractéristiques, pour chercher les concordances avec les caractéristiques de la chaîne d'objets pointée par "La petite icône". Le handle de l'objet est obtenu à partir de la liste Z order. Une fois que le handle est obtenu, il est utilisé pour envoyer un message à l'environnement Windows pour effectuer un double-clic sur l'objet identifié par le handle. Cette procédure est mise en oeuvre pour chacun des mots-clé qui spécifient une action à effectuer sur un objet. Des stratégies différentes sont nécessaires pour des mots-clé qui sont des SYNC (synchronisations). Un exemple est fourni par la troisième entrée du fichier script de la table II. La synchronisation s'applique à l'objet pointé par le pointeur désigné par "La boîte de dialogue". Il y a un événement "Ouverture" associé à l'objet. Le nom de lien "La boîte de dialogue" pointe vers une chaîne d'objets comme dans l'exemple ci-dessus pour la première entrée du fichier script. Un objet dans la liste interne à Windows des Z order correspond à la chaîne d'objet par recherche et comparaison des caractéristiques de l'objet comme ci-dessus. Une fois que objet est identifié dans la liste Z order, son handle est obtenu en utilisant des appels aux fonctions de l'environnement Windows. Cela permet au système de recevoir les messages appartenant à l'objet "La boîte de dialogue" et de détecter un événement spécifié. Dans cet exemple, l'événement spécifié est "Ouverture". Dans l'application exemple, un processus séparé, comme le moteur de surveillance, surveille les messages indique que le statut des objets sur lesquels se synchroniser. Quand un message indique le statut d'un objet sur lequel il faut se synchroniser est reçu, le moteur de surveillance positionne un indicateur. Par exemple, lorsque "la boîte de dialogue" est ouverte, un message est envoyé par Windows et ce message est intercepté par le moteur de surveillance de la présente invention. L'indicateur que positionne le moteur de surveillance est détecté par la procédure qui exécute le fichier script de la table II. La procédure exécutant le fichier script de la table lI attend la synchronisation. Par exemple, la troisième entrée du fichier script attend l'indicateur signalant que "la boîte de dialogue" a été ouverte. Dès lors que la procédure d'exécution du script détecte l'indicateur, l'exécution se poursuit au niveau des entrées suivantes du fichier script. On peut remarquer que le fichier script de la table 1l contrôle ainsi les objets d'un programme cible (chargé par un clic sur "La petite icône" - entrée 1). et leur commande de faire: 1 - double-clic sur la petite icône pour charger l'application, 2 - cliquer un choix de menu pour ouvrir un fichier, 3 - attendre que la boîte de dialogue soit ouverte, 4 - cliquer le bouton OK de la boîte de dialogue. 5 - attendre que la boîte de dialogue soit fermée, 6 - refermer la fenêtre principale de l'application. Ainsi, le fichier script de la table H lance un programme et ouvre un fichier. Une version plus élaborée du script pourrait donner un nom au fichier et y inscrire des donnés qu'elle aurait créées. Le fichier pourrait être sauvegardé et le programme terminé. Le fichier de script pourrait lui-même être lancé par un événement prédéterminé. C'est-à-dire que le fichier script peut être exécuté quand l'utilisateur agit sur un objet, comme en cliquant sur l'écran. L'occurrence de l'événement est déterminée par les méthodes décrites plus haut. De cette façon, la présente invention permet d'ajouter des fonctionnalités à une application existante. Un aspect critique de la présente invention réside dans sa capacité à identifier des objets basés sur des noms de lien dans le fichier script en s'assurant de la concordance des caractéristiques de l'objet comme cela a été décrit préalablement en relation avec les figures 7-9. Afin d'illustrer plus avant une méthode d'exécution de fichier scripts, I'organigramme de la figure 10 va être commenté. La figure 10 montre l'organigramme 300, une procédure d'exécution de fichiers scripts, comme le fichier script de la table II. La procédure débute à l'étape 302 par l'ouverture d'un fichier script. A l'étape 304, un test est effectué afin de vérifier s'il reste des entrées à exécuter dans le fichier script. Dans ce cas, on passe en 306 où les prochains mots-clé et noms de lien sont lus du fichier script. A l'étape 308, il est testé si le mot-clé correspond à une action ou à une synchronisation. S'il s'agit d'une synchronisation on passe en 3 18 pour trouver l'agent (actuellement l'objet de l'agent ou la chaîne d'objets) qui correspond à la chaîne d'objets de l'agent pointé par le nom de lien. Si aucun agent n est trouvé après le test de l'étape 320, alors un indicateur mémorise une erreur en étape 324 et la procédure se termine en 326. Si une concordance est trouvée, alors la procédure reste à l'étape 322 jusqu'à ce que l'indicateur pour l'objet synchronisé (pour un agent correspondant au nom de lien) ne soit positionné. Comme indiqué ci-dessus, cet indicateur peut être positionné par un processus externe à la procédure de l'organigramme 300, comme un processus analogue au moteur de surveillance discuté précédemment en relation avec le système d'aide. Le moteur de surveillance et la procédure 300 peuvent être chargés en même temps. tout comme le programme application hôte et peuvent devenir une extension de l'application binaire exécutable hôte, et par là même étendre ses fonctionnalités tout en apparaissant comme partie intégrante de cette application. Une fois que le positionnement de l'indicateur pour l'objet synchronisé est détecté à l'étape 322, I'exécution reprend à l'étape 306, où la prochaine entrée du fichier script est recherchée. A l'étape 308, si le mot clé n'est pas SYNC, mais donc une action, on passe en 310. L'étape 310 cherche la chaîne d'objets d'un agent qui correspond à la chaîne d'objets de l'agent pointé par le nom de lien. Si l'on suppose qu'un agent est trouvé, l'étape 312 provoque l'exécution de l'étape 314, de sorte que l'objet correspondant à l'agent soit comparé aux objets de la liste d'ordre (Z order). A l'étape 315, un test est effectué pour vérifier si le handle de l'objet de l'agent a été obtenu. Si le handle est trouvé. alors des messages sont envoyés à l'environnement Windows pour effectuer l'action indiquée par le mot-clé et l'exécution reprend à l'étape 306 où les entrées suivantes du fichier script sont prises en compte. Si l'agent n'est pas trouvé en 312 ou que le handle de l'objet n'est pas obtenu, un indicateur d'erreur est positionné en 324 et la procédure s'arrête en 326. Quand il n'y a plus d'entrées dans le fichier script, comme détecté en 304, la procédure de l'organigramme 300 se débranche vers l'étape de sortie 326. Un exemple d'application cible à automatiser ou que l'on peut enrichir (en ajoutant des fonctionnalités) : un tableur. Un tableur typique présente des cellules dans lesquelles on peut entrer des formules. La fonctionnalité ajoutée peut revêtir la forme d'un système d'aide, ou, plus généralement. d'un assistant, sous la forme d'un fichier script, qui présente à l'utilisateur un menu pour choisir les formules. L'utilisateur doit choisir une formule, et la formule choisie est automatiquement entrée dans la cellule désirée du tableur. Il serait possible de citer bien d'autres exemples d'ajouts de fonctionnalités selon le même procédé et qui se limite pas à une application particulière. Dans l'application exemple, il y a deux méthodes pour attacher des fonctionnalités à une application particulière. Le moteur de surveillance peut être lancé au chargement du système d'exploitation ou de Windows, ou bien le moteur de surveillance peut être lancé ultérieurement, au moment de la première exécution de l'application hôte. Dans la première méthode, un test est effectué pour l'apparition d'une application, ce test étant basé sur un top d'horloge. Quand l'application devient active, elle est automatiquement ajoutée à la liste des tâches surveillées. Cette liste des tâches est la liste examinée par le moteur de surveillance. Dans la deuxième méthode, le moteur de surveillance est chargé en premier, et il charge lui-même l'application automatiquement. Le moteur de surveillance détecte alors l'apparition d'une ou de plusieurs nouvelles fenêtres principales de l'application hôte et les ajoute à la liste des tâches surveillées. L'application exemple permet à un utilisateur d'obtenir une version "embarquée" d'un programme exécutable enrichi de nouvelles fonctionnalités, selon le procédé décrit dans la deuxième méthode. U est possible d'ajouter des fonctionnalités grâce à la présente invention, comme exposé ci-dessus. La version "embarquée" de l'application enrichie est lancée, ou invoquée, de façon identique que l'application originelle, de sorte que le programme et les données nécessaires pour ajouter des fonctionnalités sont invisibles pour l'utilisateur. L'utilisateur ne peut pas détecter que l'application a été renommée. A titre d'exemple, supposons que l'application originelle (sans fonctionnalités ajoutées) ait pour nom "Write.exe". Un fichier de surveillance est créée et son nom est "Write.srv". Le fichier de surveillance est un fichier binaire qui contient des informations comme un fichier script (comme décrit précédemment) et qui permet d'ajouter des fonctionnalités à l'application originelle. Le moteur de surveillance doit être chargé préalablement pour surveiller les actions de l'utilisateur et effectuer lui-même des actions quand l'utilisateur sélectionne un objet à qui une action prédéfinie a été associée. Dans l'application exemple, le moteur de surveillance avait pour nom "hmrun.exe", changé récemment en "wysilink.exe". Le programme hmrun.exe doit être renommé pour prendre le nom de l'application originelle "write.exe" dans notre exemple. Cela veut dire que quand l'utilisateur lance write.exe, c'est hmrun.exe qui est en fait chargé à sa place. L'application write.exe est aussi renommée. Dans l'exemple, on peut lui donner le nom write2.exe. Le nouveau nom de l'application est mémorisé dans le fichier write.srv. Le programme hmrun.exe renommé accède au fichier write.srv, modifié pour obtenir le lancement de l'application sous son nouveau nom, et pour obtenir et exécuter les entrées du fichier script afin de fournir les fonctionnalités ajoutées. Afin d'illustrer plus en détail cet exemple, la table III ci-dessous montre le pseudo code qui décrit cette étape effectuée par le programme hmrun.exe pour atteindre cet "embarquement" transparent. La première ligne du pseudo code de la table m permet d'obtenir le nom qui a été utilisé pour charger le moteur de surveillance. Cela ne pose pas de problèmes. Par exemple, dans l'environnement Windows, c'est le paramètre système 0 - param(0) qui retourne le premier item de la ligne de commande de lancement du programme. Si le programme a été chargé après un clic sur une icône, le paramètre 0 est aussi positionné par l'environnement Windows comme si le programme avait été chargé par l'invocation d'une ligne de commande. Une fois le nom de chargement du programme obtenu, la ligne 2 teste le nom pour savoir s'il s'agit du nom original "hmrun" donné au moteur de surveillance. Si le nom a été changé, il est supposé que le moteur de surveillance a été "embarqué" dans le programme applicatif. Les lignes 3, 4 et 5 sont exécutées dans ce cas. La ligne 3 forme le nom du fichier de surveillance (le fichier ".srv") en supposant que le fichier de surveillance et le moteur de surveillance ont la même racine. La ligne 4 permet d'obtenir tous les paramètres qui ont pu être donnés lors du chargement du moteur de surveillance, dans le but de les passer au programme applicatif que ces paramètres concernent. La ligne 5 forme une ligne de commande du nom complet de l'application avec ses paramètres. La ligne 10 du pseudo-code - table m charge alors l'application et lui passe les paramètres. Si au contraire le nom testé en ligne 2 correspond au nom du moteur de surveillance "hmrun", il est alors supposé que le moteur de surveillance n'est pas embarqué dans l'application et que le fichier script correspond au premier paramètre de la ligne de commande, obtenu par: srvfile :=Param(l) en ligne 7. La ligne 8 récupère une ligne de commande dans le fichier .srv pour le nom du programme à exécuter. Dans l'exemple cité plus haut, il s'agirait du nom write.exe, ainsi que de tous les paramètres à passer à ce programme. Comme dans le premier cas, l'exécution de la ligne 10 permet de lancer l'application. Ainsi, le pseudo-code de la table m montre comment un moteur de surveillance embarqué peut être invoqué de façon transparente pour l'utilisateur en laissant croire à l'utilisateur qu'il appelle un programme applicatif ("write.exe"), alors qu'il lance en fait le moteur de surveillance qui a reçu le nom du programme applicatif originel, qui a été lui même renommé. Cette méthode d'embarquement transparent marche aussi bien que le lancement ait lieu via une ligne de commande ou une icône. Dans le cas d'un lancement par icône, l'icône de write a été recopiée préalablement dans le moteur de surveillance renommé. De cette façon, le moteur de surveillance hmrun.exe est lancé avec la même icône que celle que l'utilisateur a l'habitude d'utiliser pour charger ce programme applicatif. Pour plus d'informations sur la recopie d'une icône et sur le mécanisme d'embarquement de programmes, il est possible de se référer à: -"Microsoft System Journal - MSJ - 1991 *5, Sept - Oct" et plus précisément à un article intitulé "What's in There? Windows 3.0 Executable and Resource File Formats Revealed" par Miller Freeman, Inc., San Mateo, Californie. -"Help Maker - Manuel d'apprentissage" DDTEC 1992. Dans la spécification qui s'achève, l'invention a été décrite avec une référence à une application exemple: développement d'un système d'aide. ll est cependant évident que différentes modifications et changements peuvnt être effectués sans changer l'esprit et la portée de l'invention. Par exemple, divers langages de programmation et diverses techniques de programmation peuvent être utilisés pour implémenter l'invention. il est aussi clair que la logique présentée dans ces spécifications pour accomplir les tâches correspondant à la présente invention peut aussi être modifiée sans changer la portée de l'invention. De tels changements ou modifications, quel que soit leur nombre, seront considérés comme ne changeant pas l'invention dès lors qu'ils correspondront à une application normale des techniques en vigueur et de l'état de l'art. Table m 1 curname := getlaunchedname; 2 if curname o "hmrun" then begin 3 srvfile := curname + 'srv' 4 passedparm := param(l) + param(2) + ...; 5 cmd~str := curname + '2.exe' + passedparm; 6 else 7 srvfile:=Param(l); 8 cmd~str := readfile(srvfile) 9 end; 10 execute(cmdstr); REVENDICATIONS 1. Procédé pour identifier les objets dans un système d'exploitation reposant sur une interface utilisateur graphique sur ordinateur, l'ordinateur incluant une mémoire associée à un processeur, le procédé comprenant les étapes suivantes - stockage dans la mémoire des caractéristiques d'un premier objet, - obtention d'une ou de plusieurs caractéristiques d'un second objet en faisant appel aux fonctions du système d'exploitation, - utilisation du processeur pour comparer les caractéristiques des deux objets, et dans le cas où elles coïncident, d'indiquer que les deux objets sont le même objet. 2. Procédé selon la revendication 1, caractérisé par le fait que l'une des caractéristiques utilisées dans la comparaison est le titre de l'objet. 3. Procédé selon la revendication 1, caractérisé par le fait que l'une des caractéristiques utilisées dans la comparaison est la classe de l'objet. 4. Procédé selon la revendication 1, caractérisé par le fait que l'une des caractéristiques utilisées dans la comparaison est un numéro d'identification (ID) de l'objet. 5. Procédé selon la revendication 1, caractérisé par le fait que l'une des caractéristiques utilisées dans la comparaison est un style d'objet. 6. Procédé selon la revendication 1, caractérisé par le fait que l'une des caractéristiques utilisées dans la comparaison repose sur le nombre des objets parents de l'objet. 7. Procédé selon la revendication 1, caractérisé par le fait que l'une des caractéristiques utilisées dans la comparaison repose sur le nombre des objets fils de l'objet. 8. Procédé selon la revendication 1, caractérisé par le fait qu'il comprend en plus les étapes suivantes :- enregistrement d'une liste de zones rectangulaires d'un objet donné, - utilisation de l'enregistrement des zones rectangulaires pour identifier une zone rectangulaire de l'objet donné comme un objet, d'un calcul de la clé(checksum) des caractéristiques, des largeur et hauteur, ordre (Z order), position, calcul de la clé de l'image. 9. Procédé selon la revendication 1, caractérisé par le fait qu'une des caractéristiques utilisée dans la comparaison est la signature d'un objet donné (succession et caractéristiques des appels système utilisés par l'application pour dessiner l'objet à l'écran). 10. Procédé selon la revendication 1, caractérisé par le fait qu'il comprend en plus les éta pes suivantes - enregistrement des noms des items de menu d'un objet donné, - utilisation de l'enregistrement des noms des items de menu pour identifier un item de menu de l'objet donné commue un objet. 11. Procédé pour fournir de l'aide contextuelle, comprenant le procédé selon la revendi cation 1 dans un système inforrnatique manipulé par un utilisateur, le système informatique comprenant un processeur, de la mémoire, des dispositifs d'entrée d'informations par un utilisateur et un écran, le système informatique incluant en outre un système d'exploitation et un programme applicatif, l'écran d'affichage présentant une ou plusieurs images, chaque image correspondant à un objet reconnu par le sys tème d'exploitation par ses caractéristiques, l'image d'un objet pouvant être sélection née par l'utilisateur d'une façon prédéfrnie, le système d'exploitation envoyant une communication à l'application lorsque l'utilisateur sélectionne l'objet de la façon pré définie, la communication incluant les caractéristiques de l'objet, alors que la mémoire contient une liste des caractéristiques de l'objet, la caractéristique du premier objet de la liste étant associée avec le premier texte d'aide, ledit procédé comportant l'exécu tion par le processeur des étapes suivantes - interception de la communication entre le système d'exploitation et le programme applicatif, - détermination du fait que les caractéristiques de l'objet intercepté dans la communication correspondent aux caractéristiques d'un objet dans la liste des caractéristiques des objets mémorisés, et surveillés, - affichage à l'écran, en réponse à l'étape de détermination, de l'aide correspondante. 12. Procédé selon la revendication il, caractérisé par le fait qu'un objet fils est associé à un objet parent, les caractéristiques, à la fois du parent et du fils étant incluses dans la communication échangée entre le système d'exploitation et le programme applicatif quand le fils est sélectionné par l'utilisateur, selon la façon de faire prédéfinie, la mémoire incluant une liste d'agents, et une aide étant associée à chaque agent, le procédé comportant l'exécution par le processeur des étapes suivantes - interception de la communication enivre le système d'exploitation et le programme applicatif, - détermination du fait que les caractéristiques de l'agent intercepté dans la communication correspondent aux caractéristiques d'un agent dans la liste des caractéristiques des agents mémorisés, - affichage à l'écran, en réponse à l'étape de détermination de l'aide correspondante. 13. Procédé selon la revendication 12, caractérisé par le fait que chaque objet parent peut, à son tour, avoir des objets parents, permettant de créer une hiérarchie d'objets, sur laquelle s'appuie la méthode de comparaison entre l'agent figurant dans la communication et un agent mémorisé, pour enfin déboucher sur une aide associée. 14. Procédé selon la revendication 11, dans lequel de multiples instances du même programme applicatif s'exécutent sur le système informatique, la méthode comprenant en outre les étapes suivantes - utilisation d'un process donné pour charger chaque instance de l'application et obtenir un handle unique pour chaque instance, - mémorisation de chaque handle unique ; et utilisation du handle unique pour déterminer à quelle instance un objet est associé. 15. Procédé selon la revendication 11, dans lequel de multiples instances du même programme applicatif s'exécutent sur le système informatique, dans lequel chaque instance du programme applicatif possède une barre de titre, la première instance ayant une barre de titre différente de celle de la seconde instance, le procédé comprenant en outre les étapes suivantes - mémorisation des indications portées par les barres de titre de la première et de la deuxième instance, et, - utilisation des barres de titre pour déterminer à quelle instance un objet est associé. 16. Procédé selon la revendication 11, dans lequel une deuxième application s'exécute dans le système informatique, la liste des caractéristiques d'objets incluant une seconde caractéristique d'objet associée avec un second texte d'aide, le procédé comprenant en outre les étapes suivantes, exécutées par le processeur: - interception d'une seconde communication entre le système d'exploitation et l'application, la deuxième communication contenant une caractéristique d'un deuxième objet associé à la deuxième application, - déterinination du fait que la caractéristique de l'objet figurant dans la deuxième communication interceptée coincide avec la caractéristique du second objet de la liste des caractéristiques d'objets et, - affichage sur l'écran, en réponse à l'étape de détermination du deuxième texte d'aide, 17. Procédé de contrôle d'une application, le procédé s'exécutant sur un système informatique, le système informatique comprenant un processeur et de la mémoire, le système informatique supportant un environnement Windows qui attribue un handle unique à chaque objet d'une application s'exécutant sous Windows, le procédé comportant les étapes suivantes - création d'un fichier script dans la mémoire qui spécifie les actions à effectuer sur les objets d'une application hôte; - chargement de l'application hôte en mémoire pour son exécution par le processeur dans l'environnement Windows; - exécution du fichier script dans la mémoire pour effectuer des actions sur les objets d'une application hôte; - identification d'un objet dans le fichier script par comparaison des caractéristiques des objets du fichier script avec les caractéristiques d'un objet de l'application hôte, selon le procédé de la revendication 1 - obtention du handle de l'objet coïncidant de l'application hôte par l'intermédiaire de 1'environnement Wmdows; - utilisation du handle pour envoyer une communication à l'environnement Wsndows, de sorte que l'action soit effectuée sur l'objet Windows est une marque déposée propriété de la société Microsoft Corp. 18. Procédé selon la revendication 17, caractérisé par le fait qu'il inclue en outre l'étape d'inhibition des communications vers l'application hôte. 19. Procédé selon la revendication 14, dans lequel plus d'une caractéristique d'un objet est utilisée pour déterminer si l'objet coïncide, le procédé comprenant en outre les étapes suivantes - sélection d'un nombre prédéfini de caractéristiques d'un objet et leur placement en mémoire pour une comparaison ultérieure; - détermination du fait que le nombre prédéfini de caractéristiques identifie ou non l'objet par rapport aux caractéristiques d'un premier objet déjà présent dans la mémoire; - sélection de caractéristiques additionnelles de l'objet; - stockage en mémoire du nombre prédéfini de caractéristiques, ainsi que des caracté ristiques additionnelles de l'objet. 20. Procédé pour ajouter des fonctionnalités à une application hôte tout en permettant 1'exécution de l'application hôte à partir de son nom originel dans un système informatique, comprenant le procédé selon la revendication 1,ce système informatique incluant processeur et mémoire, ainsi qu'une application qui possède un nom originel à partir duquel un utilisateur en demande l'exécution, le système informatique comprenant en outre un fichier script qui spécifie les actions à effectuer sur les objets de l'application afin d'ajouter des fonctionnalités à cette application, le système informatique comprenant en outre un programme d'exécution des fichiers script, ce programme ayant un nom permettant d'en demander l'exécution, le procédé comportant les étapes suivantes, devant être exécutées par le processeur: - changement du nom de l'applicatif pour un nom différent; - changement du nom du programme d'exécution des fichiers scripts et adoption du nom originel de l'applicatif; - démarrage de l'exécution du programme script; - exécution d'une ou de plusieurs instructions du programme script afin de déterminer si celuici a été renommé; - si le programme script a été renommé, exécution d'une ou de plusieurs instructions du programme script afin de lancer l'exécution du programme applicatif, en invoquant son nouveau nom ; et - pendant l'exécution de l'applicatif, si un événement prédéterminé intervient, utilisation du programme script pour exécuter le fichier script et ajouter des fonction nalités à l'applicatif.