FR 2768826 A1 19990326 FR 9811681 A 19980918 DOMAINE DE L'INVENTION La présente invention se rapporte aux techniques pour formuler des interrogations auprès des fournisseurs de données et pour retourner les résultats sous une forme5 normalisée. ARRIERE-PLAN Les utilisateurs de l'informatique rencontrent fréquemment une quantité surabondante d'informations lors- qu'ils essaient d'utiliser un ordinateur. Un fournisseur de données tel qu'un moteur de recherche sur le réseau Internet peut retourner des milliers de "tubes" (morceaux à succès) en réponse à une interrogation simple. Un fournisseur de données dans le domaine des archives de courrier électronique dit "email" peut présenter des centaines de messages que l'on doit faire défiler afin d'en trouver un seul. Une arbores- cence de répertoires de fichiers peut lister des dizaines de milliers de documents en couches confuses. La figure 1A montre un système informatique avec une interface différente 200, 202, 204, 206, 208 pour chaque fournisseur de données 210, 212, 214, 216, 218. Pour augmenter la difficulté d'accès à ce volume d'informations, les fournisseurs de données n'utilisent pas une interface utilisateur standard. Au lieu d'apprendre une interface utilisateur polyvalente, un utilisateur doit25 acquérir la maîtrise de multiples interfaces utilisateur, ce qui constitue une tâche consommatrice de temps et frustrante. L'absence d'une interface utilisateur standard engendre du travail supplémentaire pour les développeurs de logiciels qui doivent concevoir une interface différente pour chaque fournisseur de données. Par exemple, dans un environ- nement fenêtre, un développeur de logiciels doit concevoir un nouveau contrôle avec des onglets, des boutons et une configuration globale différents afin de satisfaire aux exigences de chaque fournisseur de données. Les interfaces utilisateur existantes permettent le filtrage de jeux de données sur la base d'attributs multiples en une fois. Mais il n'est pas toujours évident en regardant une interface utilisateur de savoir comment cela doit être réalisé. Par exemple, une interface utilisateur pourrait supporter un filtrage de précision utilisant des attributs multiples d'un jeu de données seulement si un utilisateur a une connaissance avancée des attributs du jeu de données ou du langage d'interrogation. Aucune interface utilisateur standard ne permet un filtrage précis d'un jeu de données sur des attributs multiples d'une manière intuitive. Une interface utilisateur peut délivrer des interrogations encore plus précises sur un jeux de données en supportant des modes de comparaison multiples pour chaque terme d'interrogation. Par exemple, la propriété AutoFilter (AutoFiltrage) du logiciel Microsoft Excel 97 supporte des modes de comparaison multiples pour un terme d'interrogation. AutoFilter permet à l'utilisateur de spécifier de quelle manière le terme d'interrogation doit être comparé au jeu de données. Un inconvénient de la mise en euvre de AutoFilter réside dans le fait que l'utilisateur spécifie le mode de comparaison dans une boîte de dialogue à l'écart de l'inter- face utilisateur principale. Des interrogations apparentées itératives sont fréquemment émises par des utilisateurs tentant de filtrer successivement des quantités énormes de données jusqu'à l'obtention de quantités gérables de données. Par exemple, un utilisateur qui pose une interrogation simple à un moteur de recherche Internet peut recevoir en guise de réponse des milliers de grands succès ou "tubes". L'utilisateur peut ensuite formuler une interrogation plus étroite pour trouver un sous-ensemble à l'intérieur de ces réponses. L'interro- gation plus étroite est d'une manière typique "interrogation initiale + autre terme". Une redondance énorme en résulte lorsque l'inter- rogation modifiée est exécutée sur le jeu de données en entier plutôt que sur le jeu plus étroit retourné en réponse à la première interrogation. Il en résulte une redondance moindre lorsque le jeu complet des termes d'interrogation plutôt que les seules modifications apportées aux termes d'interrogation sont passées entre l'interface utilisateur et le fournisseur de données. Ces redondances conduisent à l'absence d'un retour visuel attrayant au niveau de l'inter- face utilisateur et provoquent un temps de réponse lent au niveau du filtrage d'un jeu de données. Plutôt que de montrer un jeu de données se réduisant au fur et à mesure que des critères supplémentaires sont saisis, la plupart des interfaces utilisateur existantes n'envoient une interrogation qu'après que l'utilisateur a indiqué explicitement que la formulation de l'interrogation est complète. Par exemple, un utilisateur saisit une inter- rogation et ensuite appuie sur la touche pour expédier l'interrogation. Le désavantage de ce procédé est que l'on perd l'impact visuel consistant à voir la réduction du jeu de données, au fur et à mesure que les saisies sont entrées. En conséquence, certaines interfaces utilisateur existantes effectuent un filtrage après que chaque séquence de frappes de touches correspondant à une saisie de texte est validée. Par exemple, de nombreuses applications possèdent des index d'aide qui sont parcourus dès qu'une séquence de frappes de touches est exécutée. Si l'utilisateur à besoin d'aide à propos de l'affichage", il tape "a" et l'index saute à "a". Lorsque l'utilisateur tape "f", l'index saute à "af", et ainsi de suite. L'inconvénient de ce procédé réside dans le fait qu'un système de filtrage s'enlise parfois lorsqu'il doit filtrer des jeux de données volumineux; la réactivité et la performance visuelle en souffre. Un autre inconvénient des interfaces utilisateur existantes réside dans le fait qu'elles ne permettent pas un filtrage non textuel des jeux de données. Au lieu de cela, les jeux de données sont triés selon des schémas arbitraires de textes ou de valeurs textuelles exactes, même si l'utilisateur est en tarin de rechercher une couleur, une icône, une image en mode point, ou un son dans un jeu de données. Le mode de réalisation préféré de la présente invention surmonte les défauts de l'art antérieur en pro- posant une interface utilisateur standard par laquelle un utilisateur peut interagir de manière efficace et intuitive avec un fournisseur de données peu familier. RESUME DE LgINVENTION Le mode de réalisation préféré de la présente invention se rapporte à un contrôle d'en-tête qui permet à un utilisateur de filtrer un jeu de données peu familier de manière intuitive et efficace. Le contrôle d'en-tête et l'interface utilisateur standard le contenant simplifie la tâche des utilisateurs et des développeurs de logiciels. Les utilisateurs n'ont plus besoin d'acquérir la maîtrise d'une multitude d'interfaces utilisateur. Les développeurs de logiciels n'ont plus besoin de concevoir une nouvelle interface utilisateur pour chaque fournisseur de données. Au contraire, les développeurs de logiciels peuvent fournir un minimum d'information concernant le fournisseur de données et le jeu de données à l'interface utilisateur standard. Dans le mode de réalisation décrit, l'interface utilisateur standard est présentée en tant que contrôle d'en- tête "QuickFilter" (ou "FiltrageRapide") dans un environ- nement fenêtre. L'interface utilisateur standard comprend une étiquette, un filtre, un bouton à menu déroulant pour chaque attribut d'un jeu de données affiché par un contrôle corres- pondant du type "listview" (ou "zone de liste") en colonnes. Le bouton à menu déroulant peut être actionné pour afficher un menu d'articles associés à un attribut du jeu de données. Le contrôle communique avec un fournisseur de données par un jeu d'Interfaces de Programmation d'Application (API), incorporées dans le système d'exploitation de l'ordinateur. Par ces API, le fournisseur de données envoie les jeux de données de contrôle d'en-tête et l'information de menu déroulant qui est ensuite affichée dans le contrôle d'en-tête comme partie intégrante de l'interface utilisateur standard. Le contrôle d'en-tête informe le fournisseur de données de tout changement apporté aux filtres du contrôle. Le contrôle d'en-tête informe également le fournisseur de données de toute sélection effectuée en utilisant l'infor- mation de menu déroulant fournie par le fournisseur de données. Le fournisseur de données filtre le jeu de données selon le changement de filtre et l'information de sélection reçus du contrôle d'en-tête. Chaque fournisseur de données détermine comment filtrer un jeu de données en fonction de l'information reçue du contrôle d'en-tête. Une fois le jeu de données filtré, le fournisseur de données le renvoie au contrôle de zone de liste ("listview") pour affichage. Le contrôle d'en-tête est conçu pour une utilisa- tion intuitive et aisée. Il autorise des interrogations précises, intuitives en positionnant une étiquette et un filtre pour chacun des attributs d'un jeu de données au- dessus de l'attribut affiché du jeu de données. Au fur et à mesure que les filtres sont modifiés par l'utilisateur, le jeu de données est filtré par le fournisseur de données et ré-affiché dans le contrôle de zone de liste, créant l'effet visuel du rétrécissement du jeu de données au fur et à mesure que l'entrée du filtre est reçue. Le contrôle d'en-tête accomplit cet effet de "rétrécissement" visuel en envoyant les notifications de changement de filtres sans indication explicite invitant l'utilisateur à le faire. Pour empêcher les demandes de filtres de s'accumuler et de ruiner l'effet avantageux du rétrécissement, un minuteur de filtre - réglé par le fournis- seur de données- détermine la fréquence d'envoi des demandes de filtre. Si le filtrage et le ré-affichage du jeu de données peuvent être exécutés rapidement, le jeu de données peut être filtré après chaque séquence de frappe de saisie. Par ailleurs, si le filtrage et le ré-affichage d'un jeu de données prennent plus de temps, le minuteur de filtres peut être réglé à une durée plus longue pour équilibrer la réactivité de l'affichage contre une dégradation des perfor- mances provoquée par une reconstruction trop fréquente du jeu de données. Dans le mode de réalisation décrit, les menus déroulants affichent l'information concernant les modes de comparison par lesquels un filtre pour un attribut peut être comparé au jeu de données. Le fait d'afficher cette infor- mation dans un menu déroulant à proximité de l'attribut pour lequel l'information est pertinente, fournit un autre aspect intuitif de l'interface utilisateur standard. Dans une variante de mode de réalisation, les menus déroulants affichent des contrôles personnalisés (ou ouvrent une seconde fenêtre affichant des contrôles person- nalisés) fournis par le fournisseur de données. Les contrôles personnalisés permettent à l'utilisateur de saisir des entrées de filtre non textuelles utilisées pour filtrer un jeu de données sans attributs textuels. Par exemple, un contrôle personnalisé peut être une palette de couleurs sur laquelle un utilisateur choisit une couleur qui est utilisée ensuite pour filtrer le jeu de données par couleur. Les caractéristiques précédemment mentionnées et d'autres caractéristiques de la présente invention ressortiront mieux de la description détaillée suivante qui est à considérer en regard des dessins annexes. DESCRIPTION DES DESSINS La figure 1A est un organigramme d'un système informatique avec des interfaces utilisateur existantes pour accéder à différentes bases de données. La figure lB est un organigramme d'un système informatique avec une interface utilisateur selon un mode de réalisation de la présente invention pour accéder à différen- tes bases de données. La figure 2 est un diagramme illustrant un système informatique qui sert comme environnement d'exploita- tion pour une implémentation de la présente invention. La figure 3 est l'illustration d'un contrôle à fenêtre contenant (1) un contrôle de zone de liste avec un espace pour un jeu de données, et (2) un contrôle d'en-tête avec des étiquettes pour les attributs du jeu de données, des boutons à menu déroulant, et des filtres pour les attributs. La figure 4 est une illustration du contrôle à fenêtre de la figure 3 affichant un jeu de données constitué de lignes d'objets de données décrits en colonnes d'attri- buts. La figure 5 est une illustration du contrôle à fenêtre de la figure 4 avec un bouton à menu déroulant actionné et à menu déroulant affichés après recherche de l'information de mode de comparaison à partir d'un fournis- seur de données. La figure 6 est une illustration du contrôle à fenêtre de la figure 4 après que le jeu de données a été filtré par type "MS", en mode comparaison "commence par". La figure 7 est une illustration du contrôle à fenêtre de la figure 4 après que le jeu de données a été filtré par type "Word", en mode comparaison "se termine par". La figure 8 est une illustration du contrôle à fenêtre de la figure 4 après que le jeu de données a été filtré par type "MS", en mode comparaison "commence par", et date "97", en mode comparaison "année". La figure 9A est une illustration du contrôle à fenêtre de la figure 4 après que le jeu de données a été filtré par type "MS Wor", en mode comparaison "commence par", sur laquelle le processus de filtrage a été initialisé lorsque le minuteur de filtrage a expiré. La figure 9B est une illustration du contrôle à fenêtre de la figure 9A après que le jeu de données a été filtré par type "MS Work", en mode comparaison "commence par", sur laquelle le processus de filtrage a été initialisé lorsque l'utilisateur a appuyé sur la touche . La figure 10 est une illustration d'un contrôle à fenêtre montrant un jeu de données composé d'origines et d'un menu à contrôle personnalisé qui affiche une zone pour l'entrée de filtre et une zone pour l'entrée du mode de comparaison. La figure 11 est une illustration du contrôle à fenêtre de la figure 4 montrant un menu de liste à valeur unique qui affiche chacune des valeurs uniques de la colonne au-dessus de laquelle il est localisé et qui est utilisé pour obtenir l'entrée de filtre. La figure 12 est un organigramme montrant un procédé selon un mode de réalisation de la présente inven- tion. La figure 13 est un organigramme montrant les réponses prises par le contrôle d'en-tête dans différentes circonstances. La figure 14 est une illustration d'un contrôle à fenêtre qui a lancé une fenêtre "calendrier" secondaire lorsque le menu déroulant "Modifié" est activé. La figure 15 est similaire à la figure 14 mais montre une sélection d'une plage de dates dans la fenêtre "calendrier" secondaire. La figure 16 montre une autre fenêtre secondaire qui peut être lancée par activation du menu déroulant "Modifié" - celui-ci permettant la sélection d'un attribut "Modifié" autour d'une date spécifiée. DESCRIPTION DETAILLEE L'invention est illustrée en se référant à un procédé et un appareil pour fournir une interface utilisateur standard (IUS) à un fournisseur de données arbitraire. Par l'utilisation de l'IUS, un utilisateur peut soumettre une interrogation précise à un fournisseur de données peu familier et recevoir une réponse à propos. La pertinence de la réponse varie pour maximaliser l'efficacité de l'interro- gation et l'impact visuel de l'affichage continu des résul- tats intermédiaires mis à jour d'une interrogation. Dans le mode de réalisation illustré, la normalisation de l'IUS est réalisée par l'adoption d'un ensemble d'interfaces de programmation d'application (API) par l'IUS et les fournis- seurs de données. Environnement d'exploitation de la présente invention La figure 2 et la discussion qui suit sont destinées à fournir une description générale brève d'un environnement informatique approprié dans lequel l'invention peut être implémentée. Alors que l'invention est décrite dans le contexte général d'instructions exécutables par ordinateur d'un programme d'ordinateur qui tourne sur un ordinateur individuel, l'homme de l'art admettra que l'invention peut également être mise en oeuvre en combinaison avec d'autres modules de programme. D'une manière générale, les modules de programme comportent des routines, des programmes, des composants, des structures de données, etc. qui exécutent des tâches par- ticulières ou implémentent des types de données abstraits particuliers. De plus, l'homme de l'art appréciera que l'invention puisse être mise en pratique avec d'autres configurations de système informatique, y compris des dispositifs portables, des systèmes multiprocesseurs, des appareils électroniques grand public programmables ou à base de microprocesseur, mini-ordinateurs, des ordinateurs centraux, et analogues. L'invention peut également être mise en pratique dans des environnements informatiques distribués dans lesquels les tâches sont exécutées par des dispositifs de traitement distants qui sont reliés par un réseau de com- munication. Dans un environnement informatique distribué, les modules de programme peuvent être localisés à la fois sur des mémoires de stockage locales et distantes. La figure 2 illustre un exemple d'un système informatique qui sert comme environnement d'exploitation pour l'invention. Le système informatique comprend un ordinateur individuel 120, ayant une unité de traitement 121, une mémoire système 122, et un bus système 123 qui interconnecte les différents composants du système dont la mémoire système à l'unité de traitement 121. Le bus système peut comprendre l'un quelconque de plusieurs types de structure de bus comportant un bus mémoire ou un contrôleur mémoire, un bus périphérique, ou un bus local utilisant une architecture de bus telle que PCI (interconnexion de composant périphérique), VESA (association de normalisation électronique pour la vidéo), MCA (architecture microcanal), ISA (architecture des normes industrielles) et EISA (architecture industrielle normalisée étendue), pour n'en nommer que quelques-unes. La mémoire système comprend une mémoire morte (ROM) 124 et une mémoire vive (RAM) 125. Un système de base d'entrées/sorties (BIOS), contenant les routines de base qui contribuent au transfert de l'information entre les éléments se trouvant à l'intérieur de l'ordinateur individuel 120, par exemple au cours du démarrage, est stocké dans la mémoire ROM 124. L'ordinateur individuel 120 comprend de plus une unité à disque dur 127, une unité à disque magnétique 128, par exemple, pour lire un disque amovible 129 et écrire sur ce dernier, et une unité à disque optique 130, par exemple, pour lire un CD-ROM (disque optique numérique) 131 ou pour lire un support optique et écrire sur ce dernier. L'unité à disque dur 127, l'unité à disque magnétique 128, et l'unité à disque optique 130 sont connectées au bus système 123 par une interface d'unité à disque dur 132, une interface d'unité à disque magnétique 133, et une interface d'unité optique 134, respectivement. Les unités (c'est-à-dire les lecteurs ou lecteurs/enregistreurs) et leurs médias lisibles par ordina- teur respectif assurent un stockage non volatil des données, des structures de données, des instructions exécutables par ordinateur (des codes de programme tels que des bibliothèques de liens dynamiques, et des fichiers exécutables), etc., pour l'ordinateur individuel 120. Bien que la description des médias lisibles par ordinateur ci-dessus se réfère à un disque dur, un disque magnétique amovible et à un disque optique numérique, le système peut également comprendre d'autres types de médias qui sont lisibles par un ordinateur, tels que des cassettes magnétiques, des cartes à mémoire flash, des disques vidéo numériques, des cartouches de Bernoulli, et analogues. Un certain nombre de modules de programme peuvent être stockés dans les unités et la mémoire RAM 125, y compris un système d'exploitation 135 (par exemple Windows NT, Windows 95, MS-DOS, etc.), un ou plusieurs programmes d'application 136, d'autres modules de programme 137, et des données de programme 138. Un utilisateur peut entrer des commandes et des informations dans l'ordinateur individuel 120 au moyen d'un clavier de saisie 140 et d'un dispositif de pointage, tel qu'une souris 142. D'autres dispositifs d'entrée (non représentés) peuvent inclure un microphone, un manche à balai, une manette de jeu, une antenne parabolique, un scanner ou analogues. Ces dispositifs d'entrée et d'autres encore sont souvent connectés à l'unité de traitement 121 par une interface de port série 146 qui est couplée au bus système, mais peuvent être connectés par d'autres interfaces, tels qu'un port parallèle, un port de jeu ou un bus série universel (USB). Un moniteur 147 ou autre type de dispositif d'affichage est également connecté au bus système 123 via une interface, telle qu'un adaptateur vidéo 148. En plus du moniteur, les ordinateurs individuels comportent de manière typique d'autres périphéries de sortie (non représentées), telles que des haut-parleurs et des imprimantes. L'ordinateur individuel 120 peut opérer dans un environnement mis en réseau en utilisant des connexions logiques à un ou plusieurs ordinateurs distants, tels que l'ordinateur distant 149. L'ordinateur distant 149 peut être un serveur, un routeur, un dispositif pair ou un autre noeud du réseau commun, et comporte de manière typique plusieurs ou tous les éléments décrits par rapport à l'ordinateur in- dividuel 120, bien que seule une mémoire de masse 150 ait été illustrée sur la figure 2. Les connexions logiques décrites sur la figure 2 comprennent un réseau local (LAN) 151 et un réseau étendu (WAN) 152. De tels environnements de gestion de réseau sont banals dans les bureaux, les réseaux informati- ques inter-entreprises, les réseau intranets et l'Internet. Lorqu'il est utilisé dans un environnement réseau LAN, l'ordinateur individuel 120 est connecté au réseau local 151 par une interface réseau ou adaptateur 153. Lorsqu'il est utilisé dans un environnement réseau WAN, l'ordinateur individuel 120 comporte de manière typique un modem 54 ou autre moyen pour établir la communication sur le réseau étendu 152, tel que l'Internet. Le modem 154, qui peut être interne ou externe, est connecté au bus système 123 via l'interface de port série 146. Dans un environnement mis en réseau, les modules de programme décrits par rapport à l'ordinateur individuel , ou des parties de ces modules, peuvent être stockés dans le dispositif à mémoire de masse distant. On appréciera le fait que les connexions réseau montrées soient un exemple et que d'autres moyens pour établir des liaisons de com- munication entre les ordinateurs puissent être utilisés. Le contrôle d'en-tête et l'interface utilisateur standard Les figures lB et 3-13 illustrent la fonction- nalité du contrôle d'en-tête et du contrôle de zone de liste qui comprend l'interface utilisateur standard (IUS) d'un mode de réalisation de la présente invention. Les figures lB et 3-8 montrent les fonctionnements du contrôle d'en-tête et de l'IUS d'une manière globale, alors que les figures 9A et 9B montrent comment le minuteur de filtre pour des entrées de filtre textuelles fonctionnent à l'intérieur de l'IUS. Les figures 10 et 11 montrent des variantes de mode de réalisa- tion de la présente invention utilisant des menus à contrôle personnalisé et des listes à valeur unique, respectivement. Les figures 12 et 13 sont des organigrammes décrivant plus généralement le fonctionnement du système illustré. La figure lB représente à titre illustratif une IUS (interface utilisateur standard) selon la présente invention. A la différence des multiples interfaces utilisa- teurs (IU) requises pour accéder aux fournisseurs de données multiples 210, 212, 214, 216, 218 selon les méthodes de l'art antérieur, la présente invention fournit une IUS 220 unique pour accéder à de multiples fournisseurs de données. L'IUS 220 illustrée peut accéder à n'importe quel fournisseur de données conçu selon les API détaillées ci- dessous. Par exemple, 1'IUS peut être utilisée pour accéder à une arborescence de répertoire de fichier 212 par un gestionnaire de fichier 202 utilisant les API décrites ci- dessous. La même IUS peut être utilisée pour accéder à des tableurs 216, le réseau Internet 214 ou des archives de courrier électronique (EMAIL) 218. L'IUS 220 offre des avantages aux utilisateurs de systèmes informatiques et aux concepteurs de logiciels. Les utilisateurs n'ont plus besoin d'apprendre différents langages d'interrogation ou de se rappeler comment manipuler différentes interfaces afin d'accéder à des fournisseurs de données différents. Des développeurs de logiciel n'ont plus besoin de concevoir des interfaces fournisseurs de données- utilisateurs spécifiques. Au contraire, les développeurs de logiciel peuvent se fier aux caractéristiques de l'IUS (interface utilisateur standard). La figure 3 montre un contrôle 222 contenant l'IUS 220 après que le contrôle a été lancé par l'utilisa- teur. L'IUS illustrée sur la figure 3 est une partie d'un contrôle autonome. Dans une variante de réalisation, l'IUS est une partie d'un autre contrôle d'interrogation. Le contrôle 222 comporte une zone 310 pour l'affichage d'un jeu de données (comprenant des colonnes 350, 352, 354, 356 pour les attributs), d'étiquettes 320, 322, 324, 326 pour les attributs du jeu de données, de filtres 330, 332, 334, 336 pour les attributs du jeu de données, et de boutons à menu déroulant 340, 342, 344, 346 à proximité des étiquettes des attributs. Le nombre des attributs et des étiquettes des attributs est connu lorsque le contrôle est lancé. Dans une variante de réalisation, le nombre des attributs et des étiquettes destinées aux attributs est glané à partir du jeu de données affiché dans le contrôle. Dans tous les cas, le nombre de colonnes et d'étiquettes pour les attributs varie en fonction du jeu de données. Dans le mode de réalisation illustré, le contrôle d'en-tête est lancé indépendamment du contrôle de zone de liste. En d'autres termes, le contrôle d'en-tête peut devenir visible avant qu'un jeu de données ne soit affiché, comme représenté sur la figure 3. Dans une variante de réalisation, le jeu de données est affiché à l'intérieur du contrôle de zone de liste aussitôt que le contrôle d'en-tête est lancé. Le fournisseur de données fournit le jeu de données de même que l'information contenue dans les menus déroulants qui sont activés en pressant les boutons à menus déroulants sur le contrôle d'en-tête. Ainsi que l'homme de l'art pourra le reconnaître, la configuration précise de la zone du jeu de données, des étiquettes, des filtres, des boutons àmenus déroulants peut être modifiée comme souhaité. La figure 4 montre le contrôle de la figure 3 affichant un jeu de données. Le jeu de données comporte des lignes 360 d'objets de données et des colonnes 370 d'attri- buts décrivant ces objets de données. Bien que le jeu de données illustré sur la figure 4 soit composé de documents d'application décrits par un nom, un type, un chemin, et une date, n'importe quel autre jeu de données peut être utilisé. Par exemple, des jeux de données peuvent comprendre des pages Web (c'està-dire à la norme World-Wide-Web) répertoriant des "tubes" selon un moteur de recherche Internet, des messages de courrier électronique stockés dans des archives de courrier électronique, ou des enregistrements de données dans un tableur. Le jeu de données est fourni par le fournisseur de données. Le contrôle de zone de liste illustré peut loger un jeu de données avec un nombre arbitraire d'objets de données ou d'attributs de données. Le contrôle d'en-tête illustré peut de la même manière loger un nombre arbitraire d'attributs de donnees. Ainsi que l'homme de l'art pourra le reconnaître, l'organisation précise du jeu de données peut être modifiée sans changer la fonctionnalité du mode de réalisation illustré. Par exemple, les lignes du jeu de données pour- raient être les attributs tandis que les colonnes pourraient représenter des objets de données. La figure 5 montre l'IUS de la figure 4 avec un bouton à menu déroulant 342 pressé et un menu déroulant 382 affiché par le contrôle d'en-tête. Le menu déroulant 382 affiche les modes de comparaison par lesquels le filtre 332 (figure 3) de l'attribut de la colonne 352 peut être appliqué au jeu de données. Par exemple, le menu déroulant pour l'attribut "Type" est affiché. En choisissant un mode de comparaison, un utilisateur peut vérifier si un membre quelconque du jeu de données possède le type qui "Commence par", "Se termine par", "Est (exactement)" ou "N'est pas" le terme saisi dans le filtre 332 pour l'attribut. Le fournisseur de données fournit l'information de mode de comparaison affiché dans le menu déroulant. Cette information peut être différente pour chaque attribut. Sur la figure 5, l'utilisateur a choisi le mode de comparaison "Commence par" avec un curseur 390 d'un dispositif de pointage. (Comme l'admettra l'homme de l'art, d'autres dispositifs d'entrée peuvent être utilisés pour choisir un mode de comparaison sans modifier la fonctionnalité du mode de réalisation illustré). Si l'utilisateur ne choisit pas un mode de comparaison pour un attribut, le fournisseur de données utilise un mode de comparaison par défaut lorsqu'une interrogation est exécutée. La figure 6 illustre 1'IUS de la figure 4 après que l'utilisateur a effectué une saisie dans le filtre Type 332 du contrôle d'en-tête. L'utilisateur a activé le filtre Type en cliquant sur le filtre en utilisant un dispositif de pointage. Sollicité par le clic sur filtre, le filtre commute vers le mode édition. L'utilisateur tape "MS" et appuie sur la touche pour envoyer une modification de données au fournisseur de données. En variante, l'utilisateur peut cliquer ailleurs sur 1'IUS avec le dispositif de pointage pour sortir du mode d'édition. Lorsque l'utilisateur sort du mode édition, le changement de filtre est envoyé par le contrôle d'en-tête au fournisseur de données. Le fournisseur de données filtre le jeu de données selon le terme de filtre Type "MS" et le mode de comparaison "Commence par" qui a pu être choisi par l'utilisateur ou peut être le mode de comparaison par défaut. Le jeu de données filtré est retourné par le fournisseur de données et affiché dans un contrôle de zone de liste. Bien qu'un fournisseur de données détermine comment exécuter une interrogation en utilisant un filtre et un mode de comparaison d'entrée, un fournisseur de données ignore normalement les filtres qui n'ont jamais été modifiés par un utilisateur. En d'autres termes, par défaut, les filtres sont à blanc (ou sinon représentés comme étant inactifs) et ne sont pas utilisés pour le filtrage. Ainsi que l'admettra l'homme de l'art, différen- tes méthodes d'activation et de sortie des filtres à des fins d'édition peuvent être utilisées sans modifier la fonction- nalité du mode de réalisation illustré. La figure 7 illustre l'iUS de la figure 4 après que l'utilisateur a sélectionné le mode de comparaison Type "Se termine par" et le filtre Type "Word". Le fournisseur de données filtre le jeu de données selon l'information de filtre et de mode qui lui a été envoyée. Le jeu de données filtré est retourné par le fournisseur de données et affiché dans le contrôle à zone de liste. La figure 8 illustre l'IUS de la figure 4 après que l'utilisateur a choisi le mode de comparaison Type "Commence par", le filtre Type "MS", le mode comparaison Date "Année", et le filtre Date "97" à l'intérieur du contrôle d'en-tête. Le contrôle affiche le jeu de données et le contrôle d'en-tête affiche les filtres après que le fournis- seur de données a filtré le jeu de données en utilisant la totalité de cette information. Le fournisseur de données détermine comment appliquer les sélections de filtre et de mode au jeu de données. Sur la figure 8, le fournisseur de données filtre des objets de données commençant par "MS" ET ayant l'année "97" En variante, un fournisseur de données peut filtrer les objets de données commençant par "MS" OU ayant l'année "97". Un fournisseur de données peut utiliser les termes de filtre et les sélections de mode dans n'importe quel algorithme de filtrage. Le processus de filtrage est invisible au contrôle d'en-tête et au contrôle de zone de liste du mode de réalisa- tion illustré. Le contrôle d'en-tête envoie les modifications de filtre et les sélections de mode au fournisseur de données (ou son programme d'interface) et le contrôle de zone de liste reçoit des jeux de données filtrés en retour. Bien que la figure 8 représente le jeu de données après filtrage selon tous les termes de l'interrogation, comme mentionné ci-dessus, les modifications de filtre sont envoyées au fournisseur de données lorsque l'utilisateur sort du mode édition pour un filtre particulier. Les sélections de mode de comparaison sont envoyés au fournisseur de données lorsqu'elles sont réalisées. Lorsque le fournisseur de données reçoit une modification de filtre ou une sélection de mode de comparaison, le fournisseur de données filtre le jeu de données selon les termes les plus récents de l'interroga- tion. Pour l'interrogation de la figure 8, le fournisseur de données a dû effectuer de multiples opérations de filtrage avant l'opération de filtrage résultant dans le jeu de données représenté sur la figure 8. Le minuteur sur les changements de filtre textuels Les figures 9A et 9B montrent l'IUS de la figure 4 travaillant avec un minuteur sur les changements de filtre textuels. Lorsque l'utilisateur édite un filtre, le minuteur mesure le temps écoulé depuis la dernière saisie au clavier entrée par l'utilisateur. Lorsqu'une saisie au clavier est reçue, elle est groupée par le contrôle d'en-tête jusqu'à ce qu'elle soit envoyée au fournisseur de données en tant que changement de filtre. Le contrôle d'en-tête envoie automati- quement les entrées regroupées lorsque l'utilisateur sort du mode d'édition pour le filtre. De plus, si le temps écoulé depuis la dernière saisie au clavier revue (ou le temps écoulé depuis la dernière interrogation envoyée au fournis- seur de données) est au-dessus d'une certaine limite, la saisie au clavier groupé est envoyée au fournisseur de données. En se référant à la figure 9A, supposons qu'un utilisateur du mode réalisation illustré soit un novice en matière de dactylographie et que le minuteur soit réglé pour 2 secondes. L'utilisateur veut filtrer le jeu de données de la figure 4 selon le Type "MS Works". L'utilisateur tape "MS Wor", mais avant que l'utilisateur puisse trouver la lettre "k" sur le clavier, le minuteur expire et le changement de filtre Type "MS Wor" est envoyé au fournisseur de données. Le jeu de données filtré selon le Type "MS Wor" et le mode de comparaison "Commence par" (défaut) est retourné et affiché. En se référant à la figure 9B, supposons que l'utilisateur trouve ensuite la lettre "k" et tape "ks ". La touche provoque la sortie de l'utilisateur du mode édition, envoyant automatiquement le changement de filtre Type "ks" devant être envoyé au fournis- seur de données immédiatement sans attendre l'expiration du minuteur. Le jeu de données filtré selon le Type "MS Works" et le mode de comparaison "Commence par" (défaut) est retourné et affiché. Le minuteur dans le mode de réalisation illustré est réinitialisé après que chaque séquence de frappe au clavier de saisie soit reçue. Si le minuteur est réglé pour 3 secondes, une pause de moins de 3 secondes entre les séquences au clavier provoque le regroupement des séquences de frappe au clavier dans un changement de filtre unique et la réinitialisation du minuteur après chaque séquence de frappe au clavier. Une pause de 3 secondes ou plus après que la dernière séquence de frappe au clavier a été reçue provoque l'envoi de l'entrée au clavier groupé en tant que changement de filtre. Dans le mode de réalisation illustrée de l'inven- tion, le minuteur est réglé par le fournisseur de données et peut-être modifié. Si le fournisseur de données règle le minuteur avec une très courte durée, les filtres du fournis- * seur de données après chaque séquence de frappe au clavier sont entrés. Dans un tel cas, si l'opération de filtrage du fournisseur de données prend plus de temps que la frappe des séquences de saisie, le fournisseur de données peut s'enliser dans les demandes de filtre, provoquant des réponses visuel- les lentes dans le réaffichage des jeux de données et provoquant une réponse lente lorsque l'utilisateur initialise explicitement une opération de filtrage en sortant du mode d'édition. Par ailleurs, lorsque le minuteur est réglé pour une durée longue, l'IUS perd l'impact visuel avantageux du "rétrécissement" d'un jeu de données au fur et à mesure que l'utilisateur frappe des séquences de saisie. En conséquence, le fournisseur de données règle le minuteur pour équilibrer la réactivité de l'IUS à l'encon- tre de la dégradation des performances provoquée par une reconstruction trop fréquente du jeu de données. Si le fournisseur de données devient plus ou moins occupé, le temps optimal peut changer. Par exemple, si le fournisseur de données est un moteur de recherche Internet, le temps sera plus long aux heures de pointe d'utilisation de l'Internet et plus court aux heures creuses d'utilisation de l'Internet. Ainsi que le reconnaîtra l'homme de l'art, s'il était possible de prédéterminer un temps optimal pour le fournisseur de données, le minuteur pourrait être réglé par le contrôle d'en-tête une fois lancé sans modifier la fonctionnalité du mode de réalisation illustré. Le menu de contrôle personnalisé La figure 10 illustre une variante de réalisation du contrôle et de l'IUS du mode de réalisation illustré. Dans ce mode de réalisation, lorsque l'utilisateur actionne le bouton à menu déroulant 342, un menu à contrôle personnalisé 402 est affiché. Le fournsiseur de données fournit le contrôle personnalisé 412 affiché dans le menu déroulant. Dans une variante de réalisation, le fournisseur de données indique au contrôle lequel d'entre plusieurs contrôles personnalisés 412 doit être affiché dans le menu déroulant. (Le contrôle 412 sélecteur de couleurs sur la figure 10 est nécessairement gris du fait des limitations en matière de reproduction dans le cadre des brevets. Dans la pratique réelle, le sélecteur de couleurs présente un spectre bidimen- sionnel de choix de couleurs). L'utilisateur interagit avec le contrôle person- nalisé 412 pour entrer (par exemple avec le curseur 390 d'un dispositif de pointage) des termes d'interrogation non textuels pour l'attribut 352 avec lequel le contrôle person- nalisé est associé. Ces termes d'interrogation non textuels utilisés comme filtres de texte sont utilisés pour filtrer un jeu de données. Par exemple, supposons que le jeu de données en cours de recherche concerne des voitures stockées par un concessionnaire local, comme détaille sur une page présentée sur le World Wide Web (système ouvert de documents hyper- textuels de l'Internet). Un attribut de chaque voiture est sa couleur. Un acquéreur potentiel de voiture avec un vocabu- laire de couleur limité (blanc, blanc cassé, vert-de-gris, etc.) serait à son désavantage en utilisant une recherche textuelle d'une voiture dans une couleur souhaitée. Pour surmonter l'inaptitude de l'utilisateur à décrire la plage complète des couleurs de voitures en termes textuels, et pour permettre un filtrage plus intuitif, le mode de réalisation illustré propose un contrôle personnalisé 412 sous la forme d'une palette de couleurs pour des couleurs de voitures. Confronté à cette palette de couleurs, l'utilisateur choisit une couleur avec le dispositif de pointage. La sélection est passee comme un changement de filtre au fournisseur de données. Le fournisseur de données filtre ensuite le jeu de données en utilisant la sélection de couleurs comme filtre. Le menu à contrôle personnalisé affiche l'infor- mation du mode de comparaison fourni par le fournisseur de données dans un menu déroulant 382 se trouvant le long du menu à contrôle personnalisé 402. Par exemple, si le contrôle personnalisé 412 consiste en une palette de couleurs, les modes de comparaison "Est proche de" et "N'est pas" peuvent être affichés. Dans une variante de réalisation, le menu à contrôle personnalisé contient le contrôle personnalisé, tandis que l'information de mode de comparaison est présentée dans un menu séparé. Dans une autre variante encore de réalisation, le menu personnalisé peut prendre la forme d'une fenêtre secondaire, lancée par l'activation d'un menu déroulant du filtre, ou par la sélection d'une entrée "personnalisée" sur le menu déroulant. La figure 14 représente un tel agencement, dans lequel une fenêtre "calendrier" secondaire est lancée lorsque l'utilisateur active le menu déroulant "Modifié". L'utilisa- teur peut cliquer sur une date unique dans le calendrier ou, comme représenté sur la figure 15, peut faire glisser le dispositif de commande du curseur à travers une plage de dates dans la fenêtre calendrier. Dans le premier des cas, une date unique est entrée dans le champ filtre "Modifié"; dans le dernier des cas, une plage de dates est entrée. La figure 16 représente un autre exemple d'une fenêtre secondaire qui peut être lancée lorsqu'un utilisateur active le bouton du menu déroulant "modifié". Dans cet exemple, la fenêtre secondaire permet à l'utilisateur de prélever l'une de plusieurs conditions, par exemple "Le", "Entre" ou "Aux environs de". Si un utilisateur sélectionne "Aux environs de", un contrôle échelle s'active qui permet l'entrée de la plage de temps autour de la date spécifiée satisfaisant aux critères de filtre. Si l'on revient au sélecteur de couleurs person- nalisé, si les données de couleurs sont stockées chez le fournisseur de données sous forme quantitative (par exemple RGB, YUV, etc.), alors la condition "est proche de" peut être satisfaite par des couleurs dont les composantes de couleurs correspondantes sont toutes numériquement situées à l'inté- rieur, par exemple, des 15 % des composantes de couleurs de la couleur choisie par l'utilisateur. (Dans une variante de réalisation, des plages de pourcentage différentes peuvent être utilisées pour des composantes de couleurs différentes lorsqu'il faut juger de la "proximité", selon la sensibilité de différenciation des différentes couleurs par l'oeil humain). Bien que non représentées sur la figure 10, d'autres relations de couleurs qui peuvent être spécifiées comprennent "plus clair que" et "plus foncé que". Ces relations peuvent être ajustées, par exemple, en convertis- sant la couleur sélectionnée par l'utilisateur en une valeur correspondante sur une échelle de gris, et en comparant cette valeur avec des valeurs correspondantes sur une échelle de gris des couleurs stockées chez le founisseur de données. La liste à valeur unique La figure 11 illustre une variante de mode de réalisation du contrôle d'en-tête et de 1'IUS de la figure 4. Dans ce mode de réalisation, lorsque l'utilisateur actionne le bouton à menu déroulant 342, un menu de liste à valeur unique 422 est affiché. La liste à valeur unique énumère les valeurs uniques de l'attribut avec lequel la liste à valeur unique est associée. Par exemple, la liste à valeur unique de la figure 11 affiche "MS Word", "MS Excel", "MS Works" et "Texte", - une liste exhaustive de tous les types de données stockés chez le fournisseur de données. La liste à valeur unique affichée dans un menu déroulant est utilisée par l'utilisateur pour sélectionner une valeur avec le dispositif de pointage. Cette sélection est passée comme changement de filtre au fournisseur de données qui utilise ensuite la sélection de valeur unique pour filtre le jeu de données. Le fournisseur de données fournit la liste de valeur unique. Avant d'initialiser le contenu du menu déroulant, le fournisseur de données explore le jeu de données courant et détermine les valeurs uniques présentes pour un attribut donné du jeu de données. Les valeurs uniques sont renvoyées autant de fois que les modes de comparaison5 sont renvoyes. Comme mentionné précédemment, si les filtres sont réglés pour plusieurs attributs, le fournisseur de données combine ces derniers dans une opération logique ET lorsqu'il exécute l'interrogation. La liste de valeur unique permet une extension puissante de ce protocole de base: si l'utilisa- teur sélectionne plusieurs valeurs différentes dans une liste de valeur unique pour un attribut simple (par exemple en maintenant la touche Contrôle tout en sélectionnant de multiples valeurs), alors ces valeurs sont combinées dans une opération logique OU lorsque l'interrogation est posée au fournisseur de données. Cet agencement s'est avéré en test de faisabilité, comme fournissant une interface hautement intuitive. Restreindre les recherches Comme mentionné, des interrogations apparentées itératives sont fréquemment émises par des utilisateurs tentant de filtrer avec succès de grandes quantités de données pour les réduire a des quantités gérables. Par exemple, un utilisateur qui émet une interrogation simple en direction d'un moteur de recherche Internet peut recevoir des milliers de "tubes" en guise de réponse. L'utilisateur peut ensuite émettre une interrogation plus étroite pour chercher un sous-ensemble à l'intérieur de ces réponses. L'interroga- tion plus étroite est de manière typique l'interrogation originale + (ou "ET") un autre terme. Une énorme redondance est engendrée lorsque l'interrogation modifiée est exécutée sur le jeu de données entier plutôt que sur le jeu plus étroit retourné en réponse à la première interrogation. Cette redondance compromet la réaction visuelle dans une interface utilisateur et ralentit le temps de réponse. Dans le mode de réalisation illustré, la gestion de filtres réduits est laissée à la charge du fournisseur de données spécifique qui est interrogé. Lorsqu'une seconde interrogation, limitant davantage les résultats d'une interrogation immédiatement précédente, est présentée, certains fournisseurs de données peuvent exécuter la recherche à nouveau. D'autres fournisseurs de données plus intelligents, peuvent maintenir et affiner les résultats de la recherche antérieure, plutôt que la redémarrer à zéro. Les interrogations en tant qu'objets Dans de nombreuses situations, il est avantageux de passer une interrogation à un autre utilisateur au lieu de passer juste les résultats de l'interrogation. (Ces derniers peuvent être vite perimes, de même qu'ils peuvent être volumineux). Dans le mode de réalisation illustre, un utilisateur peut passer un contrôle QuickFilter à un autre utilisateur, par exemple par courrier électronique "email". Cet autre utilisateur peut ensuite exécuter l'interrogation passee quand et comme souhaité. Defilement pointé Parfois le critère de filtre peut être établi de manière si large que des centaines d'objets de données chez le fournisseur de données (ou plus) sont qualifiés pour être affichés. Dans un mode de réalisation, tous les objets de données qui satisfont aux critères de filtre sont passés au contrôle de zone de liste pour l'affichage, indépendamment de leur nombre. Dans un autre mode de réalisation, un nombre limité d'objets (par exemple deux fois plus que ce qui peut être affiché dans la fenêtre) sont passés. Ceci permet un certain défilement à travers une fenêtre, sans surcharger le système par des transferts de données intensifs. Si l'utili- sateur essaie de défiler au-delà de la dernière entrée dans la fenêtre, le fournisseur de données peut recevoir pour instruction de se munir d'objets additionnels pour affichage par le contrôle de zone de liste. Ordre de tri Dans le mode de réalisation illustré, le tri des objets affichés dans l'IUS est effectué par le fournisseur de données, qui fournit les objets au contrôle de zone de liste dans un ordre trié. Dans d'autres modes de réalisation, le tri peut être effectué du côté IUS. Le contrôle d'en-tête et les interfaces de programmation d'application Comme indiqué, le contrôle d'en-tête communique avec le fournisseur de données et le parent du contrôle au moyen d'un ensemble d'API (interface de programmation d'application). D'une manière générale, les API fonctionnent par échange de messages et de notifications. Le contrôle d'en-tête envoie des notifications au parent du contrôle et au fournisseur de données via le parent. Le contrôle d'en- tête reçoit des messages du parent et du fournisseur de données via le parent. La figure 12 est un organigramme de haut niveau du contrôle d'en-tête du mode de réalisation illustré. Comme représenté sur la figure 12, le contrôle d'en-tête est lancé en 500 par l'utilisateur. A ce point, le cadre de contrôle, les étiquettes, les filtres et les boutons à menu déroulant sont affichés. Le jeu de données peut être affiché à ce moment ou non, en fonction du fait que le contrôle de zone de liste est également initialisé ou non. Le contrôle d'en-tête peut être lancé en tant que contrôle autonome ou en tant que partie d'une fenêtre d'interrogation plus grande. Dans les deux cas, le contrôle d'en-tête a un parent par lequel il envoie et reçoit des messages. S'il est lancé dans Microsoft Windows, l'interface de programmation d'application Win32 CreateWindow API est utilisée. Si le contrôle d'en-tête est créé selon les normes de QuickFilter de Microsoft, le contrôle est décrit en messages au contrôle et des notifications à partir du contrôle en tant que structure NM_QUICKFILTER ou QF_FILTER. QF_FILTER Cette structure est passée comme partie des messages provenant du fournisseur de données impliquant des filtres individuels. Le message permet au parent d'établir ou de rechercher les valeurs de filtre courantes pour une colonne particulière. Le champ dwType indique laquelle des valeurs de filtre est valide sur la base des valeurs FILTERTYPE_*. Si dwType est FILTER_TYPE_INT alors le champ iFilter est valide. Lorsque dwType est FILTERTYPE_STRING, il est supposé que pszFilter pointe vers un tampon approprié à partir duquel établir les données de filtre ou dans lequel retourner les données de filtre. Lorsqu'il établit le filtre, le cchFilter définit la taille maximale d'édition du filtre, et lorsqu'il retourne le filtre, il définit la taille du tampon pointé par pszFilter. #define FILTERTYPESTRING OxO1 #define FILTER TYPEINT Ox03 typedef struct DWORD dwFlags; //réservé (doit être zéro) DWORD dwType; //une des valeurs FILTER TYPE union INT iFitter; //valide si dwType == FILTER_TYPE_INT struct LPSTR pszFitter; // valide si dwType == FILTER_TYPE_STRING INT cchFitter; // valide si dwType == FILTER_TYPE_STRING }); ) QFFILTER, * LPQFFILTER; NM_QUICKFILTER Lorsqu'il communique en retour avec le parent du contrôle d'en-tête par une notification WMNOTIFY, une structure NM_QUICKFILTER indique quelle colonne est le sujet de la notification. Toutes les notifications à partir du contrôle QuickFilter comportent cette en-tête. Le champ NMHDR est une partie standard de n'importe quel message de notification. iColumn indique quelle colonne à l'intérieur de l'en-tête est le sujet de la notification. typedef struct NMHDR hdr INT iCotumn; ) NMQUICKFILTER; Une fois lancé, le contrôle d'en-tête attend (520, figure 12) pour recevoir des messages. Lorsque le contrôle reçoit un message, il traduit (540) le message afin de déterminer comment agir en réponse au message. Après la traduction d'un message, le contrôle d'en-tête agit (560) sur le message avant de retourner à l'état d'attente (520) du message suivant. Une action prise par un contrôle peut être de fermer le contrôle (570), déplacer ou redimensionner le contrôle, réagencer l'apparence du contrôle, ou envoyer une notification au parent du contrôle ou au fournisseur de données via le parent. De nombreux messages sont des messages standards pour manipuler un contrôle d'en-tête et n'ont pas trait spécifiquement au contrôle du mode de réalisation illustré. Par exemple, s'il est implanté dans un environnement fenêtre, le contrôle du mode de réalisation illustré reçoit des messages Win32 HDM_ du parent qui lui indique de réagencer les colonnes du contrôle. Le contrôle reçoit également d'autres messages standards Win32 du parent qui lui indiquent de déplacer ou redimensionner le contrôle. Le contrôle d'en-tête reçoit des messages HDM du fournisseur de données via le parent qui fournissent le jeu de données affiché comme partie de l'interface utilisateur standard. Le contrôle d'en-tête reçoit de plus des messages HMENU du fournisseur de données via le parent qui fournissent l'information affichée dans les menus déroulants. En plus de ces messages standards, le contrôle d'en-tête reçoit d'autres messages qui sont spécifiques au contrôle du mode de réalisation illustré. Ces message sont décrits dans les paragraphes suivants. Messages et Notifications API Le contrôle d'en-tête illustré répond aux messages lui ordonnant d'établir un filtre, d'obtenir un filtre, de montrer/cacher tous les filtres, de positionner le 5 parent vers lequel les notifications sont envoyées, et de régler la durée du minuteur de filtre. Si le contrôle d'en-tête est conçu selon les normes de QuickFilter de Microsoft, les messages commandant au contrôle d'exécuter les actions ci-dessus sont implémentés comme suit. QFM_SETFILTER Le parent envoie ce message pour régler la valeur du filtre pour une colonne particulière. wParam contient la colonne sur laquelle régler le filtre, qui15 est supposé avoir été préalablement ajouté au contrôle QuickFilter par HDM_SETITEM. lParam contient un pointeur vers une structure QFFILTER. Si le filtre est un filtre entier (FIL- TER_TYPE_INT) la valeur est simplement stockée en mémoire. Lorsque le contrôle d'édition est créé pour permettre à l'utilisateur de modifier la valeur, les bits de style correspondants sont positionnes pour permettre à l'utilisa- teur de n'entrer que des chiffres. Si le filtre est un filtre chaîne (FIL- TER_TYPE_STRING) une copie de la chaîne pointée vers pszFilter est effectuée. Lorsque la valeur de chaîne est éditée, le cchFilter est utilisé pour limiter le nombre de caractères que l'utilisateur peut taper. L'appel retourne la valeur VRAI si l'opération est réussie. QFM_GETFILTER Le parent envoie ce message pour obtenir la valeur de filtre pour une colonne particulière. wParam contient la colonne à partir de laquelle obtenir le filtre. lParam contient un pointeur vers une structure QF_FILTER. La structure est remplie pour contenir les contenus et des types de filtres courants. Il est supposé que le fournisseur de données connaît le type du filtre pour une colonne particulière et que la structure QFFILTER contient un pointeur de tampon et une taille valides. Si le filtre est FILTER_TYPE_INT, la valeur entière est simplement stockée dans la structure. Si le filtre est FILTER_TYPE_STRING, la chaîne est copiée vers le tampon fourni par le fournisseur de données si ce tampon est suffisamment large. Sinon, l'appel échoue. L'appel retourne la valeur VRAI s'il est réussi. QFMSHOWFILTER Par défaut la barre de filtre pour le contrôle est visible. Ce message permet à l'appelant de la montrer ou de la cacher sur la base de la valeur dans wParam. Si wParam n'est pas zéro, alors la barre de filtre est montrée, sinon elle reste cachée. L'appel retourne l'état visible antérieur de la barre de filtre. QFM_SETNOTIFYTARGET Lorsqu'on utilise le contrôle d'en-tête QuickFilter pour remplacer le contrôle d'en-tête standard dans une zone de liste, les notifications sont envoyées vers la zone de liste par défaut, étant donné qu'elle constitue le parent du contrôle. QuickFilter peut spécifier qu'au lieu de cela, les notifications soient envoyées à la fenêtre décrite dans HWND de lparam. L'appel retourne à une valeur VRAI s'il réussit. QFMSETCHANGETIMEOUT Lorsqu'il édite un filtre, le contrôle QuickFilter groupe les éditions et envoie une notification unique (QFN_CHANGE) après une période spécifiée. Ce message permet à un fournisseur de données de modifier ce délai par rapport à sa valeur par défaut, qui est le double du délai d'un double clic. lParam contient le temps en millisecondes pour régler le minuteur de filtre. L'appel retourne une valeur VRAI s'il réussit. Le contrôle d'en-tête illustré envoie également des notifications indiquant au fournisseur de données qu'un filtre a été modifié, demandant au fournisseur de données de retourner un menu déroulant, indiquant au fournisseur de données qu'un opérateur a été choisi, et indiquant au parent que l'édition d'un filtre a été démarrée ou accomplie. Si le contrôle d'en-tête est conçu selon les standards de QuickFilter de Microsoft, ces notifications sont implémentées comme suit. QFNCHANGE La notification QFN-CHANGE informe le parent du contrôle d'en-tête que l'un des filtres a changé. Une structure NMQUICKFILTER est passée comme paramètre et contient l'information concernant à la fois le contrôle et la colonne qui a été modifiée. Les notifications QFN_CHANGE sont envoyées après que le minuteur de filtre a expiré, après que l'utilisateur a appuyé sur la touche à l'intérieur du contrôle d'édition, ou après que l'utilisateur a sélectionné un mode de comparaison à partir du menu déroulant. La valeur retournée par cette notification est ignorée. QFN_GETOPERATORMENU La notification QFN_GETOPERATORMENU est envoyée lorsque le filtre veut afficher le menu de l'opérateur de comparaison pour une colonne particulière. Une structure NM_QUICKFILTER est passée comme paramètre et contient l'information concernant à la fois le contrôle et la colonne pour l'affichage. Le parent, à la réception de ce message, doit retourner un HMENU qui doit être affiché. Si la valeur retournée est NULL alors l'appel ignore le menu d'opérateur pour cette colonne. La valeur retournée à partir de cette nofication est soit un HMENU ou NULL. QFN_OPERATORCHOSEN Après que le menu d'opérateur de comparaison a été affiché et que l'utilisateur a effectué une sélection, le contrôle QuickFilter envoie cette notification au parent pour l'informer de la modification. La valeur retournée par ce message de notifica- tion est ignorée. Cette notification passe, comme paramètre, une structure NM_QFOPERATORCHOSEN. Ayant envoyé une notification QFN_GETOPERATORMENU, le contrôle filtre appelle TrackPopup- Menu pour l'affichage du résultat. Le code retourné à partir de ce TrackPopUpMenu est passé au parent en utilisant comme NM_QFOPERATORCHOSEN. NMQFOPERATORCHOSEN consiste en un en-tête NM_QUICKFILTER et un champ wID contenant le résultat de TrackPopupMenu en supposant qu'il n'est pas égal a zéro. typedef struct NM QUICKFILTER rnmqf WORD wID NM QFOPERATORCHOSEN; QFN BEGINFILTEREDIT QFNENDFILTEREDIT Ces deux notifications sont utilisées pour informer le parent quand un filtre est en train d'être édité. Une structure NM_QUICKFILTER est passée comme paramètre et contient l'identification de la colonne en cours d'édition. La valeur retournée par ce message de notifica- tion est ignorée. Dans les modes de réalisation utilisant des contrôles personnalisés, un objet COM de Microsoft est employé pour implémenter une interface nommée IQFCustom- Filter. Cette interface interagit entre le contrôle d'en-tête QuickFilter et le filtre personnalisé, comme suit: HRESULT IQFCustomFilter::Edit (HWND hwndParent, POINT, ptHit, HWND phWnd) Lorsque l'utilisateur clique sur la zone de filtre, la méthode::Edit est appelée, passant la relative X/Y (en tant que point). La méthode retourne un HWND dans le pointeur fourni. Si l'appel retourne S_FALSE ou une erreur alors phWnd est supposé comme étant invalide. Sinon, la fenêtre est affichée, permettant à l'utilisateur d'éditer la propriété. HRESULT IQFCustomFilter::Render (HDC hDC, RECT rect, DWORD dwState) Ceci est appelé pour afficher le filtre dans la barre de filtre. L'objet ICustomFilter est responsable de la mise en oeuvre d'une représentation de la donnée qu'il maintient dans le HDC/rectangle donné. HRESULT IQFCustomFilter::GetOperatorMenu (HMENU*phMenu) HRESULT IQFCustomFilter::OperatorChosen (UINT uID) Ces messages s'attachent directement aux notifications QFMGETOPERATORMENU/QFN_SETOPERATOR envoyées par le contrôle de filtre au parent. Si l'objet ICustomFilter retourne ENOTIMPL à partir de ICustomFilter::GetOperatorMenu, la notification standard est émise. Un QFN_OPERATORCHOSEN est toujours émis pour permettre au parent de stocker l'opérateur ID. Lorsqu'on retourne le menu operateur, un HMENU est retourné vers le pointeur spécifié. Si ce dernier est NULL ou l'appel retourne S_FALSE alors il est ignoré. QFM_DISMISSEDIT wParam = fRefresh lParam = 0 Lorsque l'éditeur de filtre personnalisé a modifié l'état du filtre un QFMDISMISSEDIT est envoyé pour indiquer l'accom- plissement. fRefresh indique si l'objet filtre personnalisé doit se rendre de nouveau dans la barre de filtre. Ainsi que le reconnaîtra l'homme de l'art, la fonctionnalité du mode de réalisation illustré ne dépend pas de l'utlisation des messages et notifications de la manière exacte comme ceux décrits ci-dessus; ils sont détaillés simplement à titre d'exemples illustratifs. Le contrôle d'édition et le minuteur de filtre L'organigramme de la figure 13 montre le fonc- tionnement du contrôle d'édition et du minuteur de filtre utilisés dans le mode de réalisation illustsré. Un contrôle d'édition est lancé (600), comme décrit ci-dessus, lorsque l'utilisateur clique sur un filtre et le contrôle envoie une notification (QFN_BEGINFILTEREDIT) pour commencer l'édition du filtre. Le groupe d'entrée de10 filtre est effacé (602). Le minuteur de filtre est ensuite réinitialisé (604) à la valeur spécifiée par le fournisseur de données. Le contrôle d'édition est placé sur le filtre sur lequel l'utilisateur a cliqué. Une fois lancé, le contrôle d'édition attend des messages modifiant la durée du minuteur de filtre (620) ou clôturant l'édition (630), attend pour une saisie au clavier (640), et maintient un minuteur de filtre (650). Si le contrôle d'édition reçoit un message modifiant le minuteur de filtre (QFN SETTIMEOUT) (620), la durée du minuteur de filtre est modifiée comme spécifié par le message, et le minuteur est réinitialisé (622). Si le contrôle d'édition reçoit un message indiquant d'achever l'édition (QFN_ENDFILTEREDIT) (630), le contrôle d'édition ferme (632) et le filtre affiche la chaine de texte tel que dernièrement modifié dans le contrôle d'édition. Si le contrôle d'édition reçoit une séquence de saisie (640), le minuteur de filtre est réinitialisé (642) au niveau spécifié par le fournisseur de données (QFM_SETTIMEOUT). Si la séquence de frappe est (670), l'utilisateur a explicitement demandé que le fournis- seur de données démarre une opération de filtrage. S'il existe des modifications quelconques de filtre regroupées, ces modifications sont envoyées (674) au fournisseur de données (QFN_CHANGE) avant de fermer le contrôle d'édition. Si la frappe au clavier est tout autre chose sauf , la saisie au clavier est ajoutée (614) à un fichier de groupe contenant toutes les modifications de filtre effectuées depuis que le dernier regroupement de modifications de filtre a été envoyé au fournisseur de données (QFN_CHANGE). Le minuteur est réinitialisé (676) et enregistre le temps écoulé depuis la dernière frappe au clavier. Le contrôle attend alors pour la saisie suivante. Si le contrôle d'édition ne reçoit ni saisie au clavier (640), ni message d'expiration (620), ni signal de fin d'édition (630), le minuteur de filtre est vérifié (650). Si le minuteur de filtre a expiré (c'est-à-dire que le temps écoulé depuis que l'utilisateur a fait sa dernière saisie au clavier est supérieur ou égal au temps réglé par le fournis- seur de données), et le groupe de filtre n'est pas vide, le contrôle envoie une notification de changement de filtre (QFNCHANGE) (660) au fournisseur de données avec les modifications de filtre groupées comme paramètre (680). Le contrôle attend ensuite pour la saisie suivante. Si l'utili- sateur n'a entré aucune frappe du tout ou n'a entré aucune frappe depuis que le dernier groupe de modifications de filtre a été envoyé, le groupe est vide, le temps écoulé est nul, et le contrôle attend la saisie suivante. Ainsi que le reconnaîtra l'homme de l'art, l'ordre précis des étapes de l'organigramme de la figure 13 peut être modifié de nombreuses façons sans affecter la fonctionnalité du mode de réalisation illustré. Implémentation Web Les modes de réalisation de la présente invention trouvent une utilité particulière dans la mise en fenêtre des résultats de recherches effectuées sur la base de l'Internet. Dans de tels modes de réalisation, le fournisseur de données est d'une manière typique un ordinateur distant relié à l'ordinateur de l'utilisateur par une liaison de communica- tion. Les moteurs de recherche populaires qui peuvent constituer de tels ordinateurs distants comprennent Excite, Lycos, HotBot et Alta Vista. Dans de tels modes de réalisation, les com- munications entre l'interface d'interrogation graphique sur l'ordinateur de l'utilisateur et le fournisseur de données distant ne peuvent pas de manière courante être effectuées par les API de Microsoft Windows telles que détaillées ci- dessus. Au contraire, une telle communication est réalisée par d'autres moyens. Si le système est implémenté en langage Java ou analogues, les événements de notification Java peuvent être utilisés pour effectuer la communication. Dans d'autres modes de réalisation, les communications HTTP peuvent être utilisées. Les attributs de données par lesquels des objets Internet peuvent être filtrés comprennent la date, la taille, le domaine, l'abrégé textuel, etc. Comme dans d'autres applications basées sur le Web, le problème du temps d'attente des communications doit être traité. Dans un mode de réalisation préféré, la constan- te de temps utilisée par le minuteur (détaillé ci-dessus) est réglée de manière adaptée selon le temps d'attente réseau réel (tel que mesuré au moyen de techniques connues), de même que la charge de traitement courante sous laquelle le fournisseur de données travaille. En utilisant des applets (petites applications) Java ou analogues, un contrôle tel que celui décrit ci-dessus peut être signé et incorporé dans des pages Web, prolongeant la normalisation de cette interface à partir du propre bureau de l'utilisateur à travers le world wide web (toile d'araignée mondiale). Les principes de l'activité inventive ayant été décrits en référence à plusieurs modes de réalisation illustratifs, il est évident que la technologie peut être modifiée dans son agencement et ses détails sans sortir desdits principes. Par exemple, alors que le mode de réalisation illustré fait usage de deux structures de contrôle distinctes pour former l'interface utilisateur standard (c'est-à-dire le controle d'en-tête QuickFilter - qui ne connaît rien d'autre du jeu de données que les filtres, les étiquettes, les menus déroulants, etc., et le contrôle d'affichage de zone de liste qui ne représentent que le jeu de données), dans des variantes de réalisation, une structure unifiée peut être employée. De plus bien que l'invention ait été illustrée dans le contexte d'une interface utilisateur graphique, les concepts inventifs ne s'y limitent pas. Par exemple, les principes précédents peuvent être employés avantageusement dans des interfaces orientées texte (comme c'est le cas couramment, par exemple, dans de nombreux systèmes à gros ordinateurs). De plus, alors que l'invention a été illustrée comme utilisant une description détaillée tabulaire de chaque objet de données dans le contrôle de zone de liste, dans d'autres modes de réalisation une vue iconique plus simple des objets de données satisfaisant aux critères de filtre spécifié peut être présentée. De plus, alors que les modes de réalisation détaillés utilisent des champs de filtre pour chacun de plusieurs attributs, dans d'autres modes de réalisation, un champ de filtre unique peut être utilisé pour chercher à travers plusieurs attributs. Dans un tel mode de réalisation, le contrôle d'en-tête a un champ général "chercher". La donnée entrée dans ce champ est mise en correspondance par rapport à tous les attributs des objets de données. Tout objet ayant une correspondance (indépendamment de l'attribut possédant la correspondance) est présenté à l'affichage. Un tel champ général "chercher" peut être ajouté au champ d'attribut spécifique illustre, ou peut être utilisé à leur détriment. De manière similaire, des champs uniques peuvent être utilisés pour chercher à travers des sous-ensembles de tous les champs d'attributs (par exemple titre/abrégé/au- teur). Eu égard à la large variété de modes de réalisa- tion possibles auxquels les principes de la présente inven- tion peuvent être appliqués, il sera admis que les modes de réalisation décrits en détail ne sont donnés qu'à titre illustratif et ne doivent en aucun cas être considérés comme limitant le cadre de la présente invention. REVENDICATIONS 1. Dans un premier système informatique, un procédé pour le filtrage normalisé de données à partir d'un fournisseur de données arbitraires, le procédé étant carac- térisé en ce qu'il consiste à: recevoir un premier jeu de données du fournisseur de données arbitraires, ledit premier jeu de données compor- tant une pluralité d'objets de données et une pluralité d'attributs associés aux objets de données; afficher le premier jeu de données, conjointement avec une pluralité d'étiquettes et une pluralité de filtres, chaque étiquette décrivant un attribut du premier jeu de données; et chaque filtre étant associé à un attribut du premier jeu de données; le procédé consistant de plus à: recevoir, d'un utilisateur du système informa- tique, une entrée de filtre dans un ou plus d'un d'une pluralité de filtres; envoyer l'entrée de filtre au fournisseur de données arbitraires; recevoir du fournisseur de données arbitraires un second jeu de données, dans lequel ledit second jeu de données est dérivé en filtrant le premier jeu de données selon l'entrée de filtre; et afficher le second jeu de données avec ladite pluralité d'étiquettes et de filtres. 2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend l'affichage desdits jeux de données, desdites étiquettes, et desdits filtres, dans un contrôle fenêtre. 3. Procédé selon la revendication 2, caractérisé en ce qu'il comprend de plus: l'affichage d'une interface utilisateur d'inter- rogation, dans laquelle le contrôle est affiché à l'intérieur de l'interface utilisateur d'interrogation; la réception d'une entrée d'interrogation à partir d'un utilisateur du système informatique, l'entrée d'interrogation étant utilisée pour trier le premier jeu de données préalablement à son affichage. 4. Procédé selon la revendication 1, caractérisé en ce que les premier et second jeux de données sont des tables à lignes/colonnes d'objets de données, chaque colonne représentant un desdits attributs et chaque ligne représen- tant un objet de données unique. 5. Procédé selon la revendication 1, caractérisé en ce qu'il comprend de plus: le minutage du temps écoulé depuis que la dernière entrée de filtre a été fournie au fournisseur de données; et l'envoi de toute entrée de filtre nouvelle au fournisseur de données lorsque ledit temps écoulé excède un intervalle de seuil prédefini, ou lorsqu'un utilisateur démarre explicitement une étape d'envoi, suivant lequel de ces deux cas survient le premier. 6. Procédé selon la revendication 5, caractérisé en ce qu'il comprend de plus la réception à partir du fournisseur de données arbitraires de l'intervalle de seuil prédefini, la durée du seuil prédefini étant réglée pour équilibrer la réactivité de l'utilisateur par rapport au temps requis au filtrage des données par ledit fournisseur de données arbitraires. 7. Procédé selon la revendication 1, caractérisé en ce qu'au moins un filtre comporte une chaîne de texte, la chaîne de texte étant affichée à l'intérieur du filtre, et l'entrée de filtre étant une modification à la chaîne de texte dans un ou plusieurs d'une pluralité de filtres. 8. Procédé selon la revendication 1, caractérisé en ce qu'il comporte le transfert d'instructions de filtrage, et la fourniture de jeux de données, selon une interface de programmation d'applications prédéterminée. 9. Procédé selon la revendication 8, caractérisé en ce que l'interface de programmation d'applications comporte des fonctions pour (a) régler un filtre, (b) obtenir un filtre, (c) montrer/cacher tous les filtres, (d) régler le parent auquel les notifications sont envoyées, et (e) régler la durée du minuteur de filtre; et en ce qu'il comporte des appels de fonction/pour (a) indiquer au fournisseur de données arbitraires qu'un filtre a été modifié, (b) demander au fournisseur de données arbitraires de retourner un menu déroulant, (c) indiquer au fournisseur de données arbitraires qu'un opérateur a été choisi, et (d) indiquer à un parent que l'édition d'un filtre a été démarrée ou accomplie. 10. Procédé selon la revendication 1, caracérisé en ce que le fournisseur de données arbitraires est localisé dans la mémoire ou dans le dispositif de stockage du premier système informatique. 11. Procédé selon la revendication 1, caractérisé en ce que le fournisseur de données arbitraires est localisé dans la mémoire ou dans le dispositif de stockage d'un second système informatique, ledit second système informatique étant en communication avec le premier système informatique. 12. Dans un système informatique, un procédé pour afficher sur un dispositif d'affichage un contrôle utilisé pour filtrer des données dans un premier jeu de données, le procédé comprenant: la réception à partir du fournisseur de données arbitraires d'un premier jeu de données, le premier jeu de données comportant une pluralité d'objets de données et une pluralité d'attributs associés aux objets de données; l'affichage du premier jeu de données dans le contrôle, conjointement avec une pluralité d'étiquettes, une pluralité de boutons à menus déroulants, et une pluralité de filtres, chaque étiquette décrivant un attribut du premier jeu de données, chaque étiquette étant associée a un ensemble modes de comparaison, chaque filtre étant associé à un attribut du premier jeu de données, et au moins un filtre recevant une entrée utilisée pour modifier le premier jeu de données selon l'attribut auquel ledit filtre est associé; en réponse à l'actionnement d'un bouton à menu déroulant proche d'une étiquette, l'affichage d'un menu déroulant dont les contenus sont fournis à partir du fournis- seur de données arbitraires; la réception d'une entrée à partir de l'utilisa- teur du système informatique en réponse au menu déroulant; l'envoi de ladite entrée vers le fournisseur de données arbitraires; la réception à partir du fournisseur de données arbitraires d'un second jeu de données, le second jeu de données étant dérivé en triant le premier jeu de données selon ladite entrée; et l'affichage dudit second jeu de données. 13. Procédé selon la revendications 12, carac- térisé en ce qu'au moins un desdits menus déroulants comprend une sélection de modes de comparaison pour l'attribut auquel le menu déroulant est associé. 14. Procédé selon la revendication 12, carac- térisé en ce que le contenu du menu déroulant comprend un contrôle personnalisé pour l'attribut auquel le menu déroulant est associé. 15. Procédé selon la revendication 12, carac- térisé en ce que le menu déroulant lance une fenêtre séparée. 16. Procédé selon la revendication 12, carac- térisé en ce que le contenu du menu déroulant comporte une liste à valeur unique pour l'attribut auquel le menu déroulant est associé. 17. Procédé d'interrogation d'un fournisseur de données et de filtrage des résultats provenant de ce fournisseur, ce procédé mettant en oeuvre des instructions stockées dans un support de stockage informatique et provoquant l'exécution par un ordinateur programmé des actions suivantes: émission d'une commande de filtrage vers un fournisseur de données en réponse à une entrée utilisateur; réception des résultats en réponse à partir du fournisseur de données et affichage desdits résultats; acceptation de l'entrée utilisateur et stockage de cette dernière dans un groupe; expédition des entrées utilisateurs ainsi groupées vers le fournisseur de données lorsqu'un minuteur expire, ou lorsque l'utilisateur a explicitement commandé l'expédition des entrées groupées; et réception des résultats modifiés provenant du fournisseur de données et affichage desdits résultats. 18. Procédé selon la revendication 17, carac- térisé en ce que lesdites instructions amènent l'ordinateur programmé à réinitialiser le minuteur lorsque les entrées utilisateurs groupées sont expédiées vers le fournisseur de données. 19. Procédé selon la revendication 17, carac- térisé en ce que lesdites instructions amènent l'ordinateur programmé à réinitialiser le minuteur chaque fois que l'entrée utilisateur du minuteur est acceptée à partir de l'utilisateur. 20. Procédé selon la revendication 17, carac- térisé en ce que lesdites instructions amènent l'ordinateur programmé à recevoir un paramètre de minutage à partir du fournisseur de données, et à régler ledit minuteur selon ledit paramètre. 21. Procédé selon la revendication 17, carac- térisé en ce que ladite commande comprend un code exécutable envoyé sur une liaison de communications pour réception par un ordinateur distant sur lequel le fournisseur de données réside. 22. Procédé selon la revendication 17, caractérisé en ce que ladite commande comporte un appel API (interface de programmation d'application). 23. Procédé selon la revendication 17, caractérisé en ce que les instructions font partie d'un navigateur Web. 24. Ordinateur comprenant un support de stockage et des moyens de système d'exploitation pour ordinateur, stockés sur un support de stockage, ces moyens comprenant: un moyen pour invoquer un contrôle de filtrage générique; et un moyen pour établir une communication entre ledit contrôle de filtrage générique et un fournisseur de données arbitraires. 25. Ordinateur selon la revendication 24, caractérisé en ce que ledit moyen comporte des messages et des appels ayant une syntaxe commençant avec QFN et QFM. 26. Procédé d'interrogation d'un fournisseur de données, caractérisé en ce qu'il comprend: la fourniture d'une interface utilisateur normalisée apte à être utilisée avec une pluralité de fournisseurs de données différents; la formulation de premiers critères de recherche en utilisant ladite interface utilisateur; la transmission de données se rapportant auxdits premiers critères de recherche à un fournisseur de données; la conduite d'une première recherche de données par le fournisseur de données selon lesdits premières critères de recherche pour générer de premiers résultats, et la fourniture des résultats à l'interface utilisateur normalisée pour affichage; l'utilisation de ladite interface utilisateur, la formulation de seconds critères de recherche, lesdits seconds critères de recherche comprenant la mise en combinaison logique ET desdits premiers critères de recherche avec des critères de recherche additionnels; la transmission de données relatives auxdits seconds critères de recherche au fournisseur de données; la conduite d'une seconde recherche de données par le fournisseur de données selon lesdits critères de recherche pour générer de seconds résultats de recherche, et la fourniture desdits résultats à l'interface utilisateur normalisée pour affichage; ledit fournisseur de données conduisant la seconde recherche en filtrant les premiers résultats de recherche selon les critères de recherche additionnels (recherche itérative), ou en exécutant une nouvelle recherche comprenant à la fois les premiers critères de recherche et les critères additionnels, la même interface utilisateur étant utilisée pour conduire à la fois des recherches itératives et de nouvelles recherches lors de l'affinage d'une recherche précédente, en fonction du fournisseur de données interrogé. 27. Dans un système informatique ayant une interface utilisateur comportant un dispositif d'affichage et un dispositif de sélection d'interface utilisateur, un procédé pour formuler une interrogation vers un fournisseur de données et pour présenter des résultats de l'interrogation, comprenant les étapes consistant à: (a) identifier un jeu d'attributs de données correspondant audit fournisseur de données; (b) présenter lesdits attributs dans de premiers champs de l'interface utilisateur graphique; (c) recevoir, dans de seconds champs adjacents auxdits premiers champs, des entrées de données correspondant à l'un ou plusieurs desdits attributs; (d) interroger le fournisseur de données pour identifier des objets de données ayant des attributs cor- respondant auxdites données reçues; et (e) présenter les résultats de ladite inter- rogation sur l'interface utilisateur, organisés de manière que lesdits attributs des objets de données identifiés soient présentés en association avec les premiers champs qui leur sont associés. 28. Procédé selon la revendication 27, carac- térisé en ce que les étapes (a) à (d) sont exécutées par un contrôle d'en-têtes fenêtré, et l'étape (e) est fournie par un contrôle à affichage fenêtré séparé. 29. Procédé selon la revendication 27, carac- térisé par: l'agencement des premiers champs dans une première ligne; l'agencement des seconds champs dans une seconde ligne en dessous de la première ligne; et l'affichage d'objets de données identifiés par ladite interrogation en lignes successives en dessous de la seconde ligne. 30. Procédé selon la revendication 27, carac- térisé en ce que l'étape d'identification comporte l'obtention dudit jeu d'attributs de données à partir du fournisseur de données plutôt qu'à partir d'un codage intégré à l'interface utilisateur graphique. 31. Procédé selon la revendication 27, carac- térisé en ce qu'il comporte deux demandes d'interrogation ou plus vers le fournisseur de données au fur et à mesure que des entrées de données sont reçues dans l'un unique desdits seconds champs, la seconde desdites demandes étant beaucoup plus détaillée que la première. 32. Procédé selon la revendication 27, d'après lequel: pendant l'étape de réception, on reçoit des premiers critères de filtre à partir de l'interface, les premiers critères de filtre comprenant une pluralité de critères sélectionnés à partir d'une liste à valeur unique, ladite pluralité de sélections étant combinées dans une opération logique OU pour former lesdits premiers critères de filtre; on reçoit des seconds critères de filtre à partir de ladite interface; et pendant l'étape d'interrogation, on interroge le fournisseur de données pour identifier des objets de données dont les attributs cor- respondent à la fois auxdits premiers et seconds critères, une combinaison logique ET desdits premiers et seconds critères de filtre étant effectuée. 33. Procédé selon la revendication 27, d'après lequel les attributs comprennent des attributs non textuels, l'interface utilisateur graphique comprend une interface à filtre d'interrogation et: pendant l'étape de présentation desdits attributs, on présente dans l'interface de filtre d'interrogation un sélecteur non textuel au moyen duquel un attribut non textuel peut être sélectionné, ledit sélecteur étant fourni à l'interface de filtre d'interrogation par le fournisseur de données plutôt que d'être codé dans l'interface de filtre d'interrogation; et pendant l'étape d'interrogation du fournisseur de données, on émet des critères de recherche vers le fournisseur de données selon un attribut non textuel choisi par un utilisateur par ledit sélecteur. 34. Procédé selon la revendication 33, carac- térisé en ce que l'étape de présentation comprend l'affichage, et le sélecteur non textuel comporte la présentation d'un affichage graphique de couleurs.