Env Windows

L'environnement Windows

7. Programmation événementielle et environnement Windows

Il n'est pas envisageable de développer une "application Windows" complexe sans connaître certaines caractéristiques de cet environnement ainsi que son mode de fonctionnement interne. Pour créer une application dont le comportement correspond aux "normes" en vigueur dans cet environnement, mais aussi pour optimiser son fonctionnement.



Ce sont surtout les aspects "Interfaces graphiques" et "fonctionnement événementiel" qui sont développés dans ce chapitre. Pour ce qui est du système d'exploitation en tant que tel, il faut se reporter à des ouvrages particuliers traitant du sujet.

7.1 : Description générale Les systèmes d'exploitation Windows ( Windows 9.x ou NT ) sont des systèmes créés par la société Microsoft. Outre les services traditionnellement offerts par les systèmes d'exploitation ( gestion des tâches, gestion de la mémoire, gestion des fichiers, etc. ), Windows met en œuvre un gestionnaire de fenêtres graphique élaboré au sein duquel les applications – de quelque type qu'elles soient – s'exécutent. Ce système de gestion de fenêtre n'est pas "neutre" si l'on se place du point de vue du développeur : - Il impose un mode fonctionnement, dit "événementiel", aux applications. Celles-ci doivent donc être créées en étant en mesure de supporter ce mode de fonctionnement. - Il impose certaines normes de conception des interfaces utilisateurs. Ceci de manière à ce que les applications aient des comportements similaires afin de ne pas dépayser les utilisateurs.

Page VII. 1

L'environnement Windows



Les environnements Windows fournissent par ailleurs divers mécanismes standardisés ( presse-papiers et autres ) dont peuvent profiter les applications si ces dernières ont été développées pour les utiliser.

7.11 : Histoire de Windows L'origine de Windows est celle de tous les autres GUI ( Graphic User Interface ) utilisées dans le monde informatique : il s'appuie sur les résultats des études réalisées par la société Xerox, dans les années 70, au sein de son laboratoire PARC ( Palo Alto Research Center ) spécialisé dans les nouvelles techniques de traitements de l'information. Parmi les réussites de ce laboratoire on peut citer, entre autres, la souris, l'impression laser, les réseaux locaux et la formalisation d'une interface graphique. Mais la société Xerox n'a jamais su mettre à profit les résultats des études de son propre laboratoire. Ce sont d'autres sociétés, ayant eu vent des ces projets, qui les ont industrialisés. Les travaux sur l'interface graphique et sur la souris ont vivement impressionné Steve Jobs, un des fondateurs d'Apple. Il se lance dans une aventure qui aboutira quelques années plus tard, en 1984, à la création du Mac Intosh. Microsoft ne commença quant à lui à s'intéresser à ce type d'interface qu'en 1983, soit deux ans après l'arrivée du premier PC sur le marché ( en 1982 le système d'exploitation DOS n'en était qu'à sa version 2.0..... ). A cette époque il est vrai l'architecture même du couple PC/DOS est un frein à la généralisation d'une interface graphique : le PC type est livré avec deux lecteurs de disquettes et ne dispose que de 64 Ko de Ram, le DOS lui ne peut pas gérer une mémoire supérieure à 640 Ko. Le succès commercial d'un tableur célèbre, Visicalc, doté d'une interface pseudographique, outre le fait qu'il marque l'acte de naissance de la micro-informatique dite "sérieuse", relança les recherches chez Microsoft et chez IBM : la version 1.01 de Windows, sortie en novembre 1985, tient sur 2 disquettes et se contente de 256 Ko de Ram mais n'est guère viable. La version 2.0 suit en 1987 : elle permet la gestion des fenêtres se recouvrant et gère la mémoire EMS mais n'est toujours pas réellement au point. D'où un fiasco flagrant. En 1987 d'autres environnements graphiques sont proposés au public : outre l'environnement du Mac Intosh, IBM propose Personnal Manager sur OS / 2 et Digital Research une interface utilisable sur le DOS : l'interface GEM. La version 3.0 de Windows est livrée en mai 1990 : malgré quelques défauts et le fait qu'elle nécessite de grosses configurations ( pour l'époque ) elle est la première à rencontrer le succès. Plus qu'un succès d'ailleurs puisque ce produit est rapidement l'interface pratiquement obligée des applications tournant sur PC, surtout dans sa version 3.1 apparue en 1992. L'environnement Windows s'est – pratiquement - désolidarisé du système DOS avec l'apparition de Windows 95 ( puis de Windows 98 ) pour les postes de travail et de Windows NT ( pour les serveurs ).

7.12 : Caractéristiques fondamentales

Page VII. 2

L'environnement Windows Les différents systèmes Windows mettent en œuvre un certain nombre de mécanismes standardisés. ¤ Ils sont multitâches et même multithreads. Plusieurs applications peuvent donc s'exécuter simultanément sur le poste de travail. ¤ Ils mettent en œuvre un mécanisme de transmission de données entre les applications appelé "presse-papiers". Le presse-papiers ( clipboard ) permet le transfert de tous types de données, textes ou images, entre deux applications lancées dans l'environnement.

¤ Ils mettent en œuvre des mécanismes plus élaborés permettant de lier les applications entre elles. Le protocole DDE permet de lier deux applications entre elles : un document conçu dans une application pourra être incorporé dans un document géré par une deuxième application. Toute modification intervenant sur le document source est répercutée dans sa représentation dans le document de destination. Le protocole OLE est encore plus ambitieux : il permet de lancer l'application source simplement en double-cliquant sur la représentation du document incorporé dans le document de destination.

¤ Ils sont livrés avec des jeux de polices de caractères standardisés permettant de garantir l'affichage et l'impression corrects de textes. Windows gère les polices vectorielles True-Type. Ce format est reconnu par plusieurs systèmes d'exploitation. Grâce à ces jeux de polices on peut réaliser des documents utilisant plusieurs polices, dans plusieurs tailles et styles, sans qu'apparaissent les effets "d'escalier" dès que la police utilisée a une taille trop importante. Les applications utilisant toutes les mêmes polices, il n'est plus nécessaire de se préoccuper de fournir une application avec un jeu de polices personnalisées.

7.2 : Fonctionnement en mode événementiel Windows, comme tous les systèmes proposant une interface graphique, gère l'essentiel du dialogue homme-machine en mettant en place un mécanisme de gestion des événements. Pour que ce mécanisme soit efficace, il faut que l'application qui doit être exécutée dans l'environnement Windows soit développée en conséquence. L'écriture d'un tel programme se fait selon un mode totalement différent que celui mis en œuvre pour réaliser un programme traditionnel. -

Dans une application classique c'est le programme qui, au travers de ses diverses instructions et enchaînements de sous-programmes, dicte la démarche de l'utilisateur. C'est lui aussi qui décide quand il faut interroger le système pour que ce dernier lui fournisse certaines informations sur l'état de l'environnement d'exécution ( état du clavier en particulier pour ce qui concerne le dialogue avec un utilisateur ). C'est une routine particulière qui interroge par exemple le système pour savoir quand l'utilisateur rentre une donnée et qui bloque l'exécution de l'application tant que cette donnée n'est pas entrée.

-

Dans une interface graphique fonctionnant en mode événementiel, l'utilisateur clique où bon lui semble et quand il le désire sur les différents "contrôles" mis à sa Page VII. 3

L'environnement Windows disposition. Ce sont les actions sur ces contrôles qui assurent le dialogue entre l'utilisateur et l'application. Ils sont susceptibles de déclencher certains traitements. Il n'est plus possible, compte tenu du nombre de contrôles de tous types proposés, de réaliser des algorithmes gérant efficacement le dialogue. Pour que le programme réagisse correctement aux sollicitations de l'utilisateur il doit s'en remette au système d'exploitation support qui est le seul à être en mesure de savoir quelles ont été les actions de l'utilisateur. Celui-ci considère en effet toutes les actions réalisées avec un périphérique ( clavier ou souris en particulier ) comme étant des événements qu'il sait gérer. Lorsque l'utilisateur, ou l'application de manière programmée, opère une action ( clic de souris, activation de menu, redimensionnement, etc. ) le système génère un message "typé" qu'il stocke dans une file d'attente. A charge pour l'application de venir lire le contenu de cette file et de prendre en compte ( ou non ) les messages qui la concernent. L'application doit donc mettre en place le mécanisme qui lui permette de lire dans la file de message, d'en extraire les messages qui l'intéressent et de déclencher les sousprogrammes correspondant au message. C'est donc le système qui prévient l'application en lui envoyant des indications, appelés messages, du type "il y a tel caractère entré au clavier", "la souris est à tel endroit de l'écran", "l'utilisateur a cliqué sur le bouton gauche de la souris", etc. Au programme de prendre en compte ou non le message pour la suite de son exécution.



On utilise plus généralement le mot "d'événement". Les événements systèmes sont pris en compte par Windows qui alimente en conséquence une file de message. L'application vient lire cette file et active, après prise en compte des messages qui la concernent, les gestionnaires d'événements appropriés.

Il faut revenir sur le fait que, en dehors de l'aspect technique développé précédemment, ce mode de fonctionnement est totalement différent du mode classique de fonctionnement des applications. - Dans le cas d'un mode normal de fonctionnement, le programmeur est maître de la structure du code qu'il génère et de la manière dont les différents tests, et les actions qui en découlent, s'enchaînent. - Dans le cas d'une application événementielle, le programmeur doit développer des gestionnaires d'événements correspondants à tous les événements qui peuvent se produire. Mais il n'est absolument pas maître de l'ordre dans lequel ces événements apparaîtront ( il ne sait même pas s'ils se produiront à l'exécution ).

L'inconvénient majeur de ce mode de programmation est que le source résultant ne permet pas d'avoir une vision globale de la logique applicative. Une application événementielle n'est en effet constituée que d'interfaces graphiques, qui sont décrites et non codées, et d'une multitude de sous-programmes réalisant chacun un traitement précis. Le source n'est donc constitué que d'une succession de sous-programmes ( très nombreux et aux algorithmies souvent très réduites ) sans aucun lien entre eux. Il faut disposer à la fois de ces sources et de la description des interfaces graphiques qui constituent l'application ( des copies d'écrans commentées sont préférables ) pour être en mesure de comprendre réellement la logique qui préside l'application.

Page VII. 4

L'environnement Windows

Dans un premier temps la mise en place du mécanisme événementiel constituait une tâche très difficile à maîtriser pour les programmeurs. D'où des délais de développement prohibitifs pour un résultat peu performant. Les choses ont heureusement évoluées dans le bon sens et les environnements de développement modernes réalisent une grande partie de ce travail de manière automatique ( en particulier ils intègrent directement dans le code de l'application toute la partie concernant la lecture des messages dans la file de message alimentée par le système ). Le développeur n'a plus qu'à lier les événements qu'il souhaite prendre en compte aux blocs d'instructions ( gestionnaires d'événements ) appropriés ..... qui lui restent à coder.

On dit parfois que Windows est un environnement "piloté par événements".



Bien prendre en compte qu'au niveau interne des milliers d'événements peuvent être générés dans des délais très brefs ( pensez au déplacement d'une souris sur l'écran ).



Lorsqu'il est lancé, Windows met en place un moteur événementiel capable de récupérer les événements reçus par les différentes couches basses du système et de les placer dans une ou plusieurs files d'attente pour qu'ils soient pris en compte par les applications en cours d'exécution.

Figure 1 : Schématisation du mode événementiel

Page VII. 5

L'environnement Windows

7.3 : Architecture système de Windows Sans entrer dans des détails trop techniques il est cependant nécessaire d'avoir quelques idées sur la manière dont les différents systèmes Windows 9x sont architecturés pour pouvoir optimiser les applications développées.

7.31 : Les composants systèmes Le noyau de Windows est constitué d'un ensemble de fonctions systèmes regroupées principalement dans trois bibliothèques système ( Kernel, User et GDI ) et de divers drivers. A ce noyau se rajoute une pléthore d'utilitaires et de drivers utilisés dans certains contextes ( extensions multimédias entre autres ). Mais tous s'adressent au noyau évoqué précédemment. On peut schématiser cette structure comme suit :

Utilitaires"système" "système" Utilitaires

Applications Applications

Interface de programmation ( API )

GDI GDI

User User Kernel Kernel

Drivers divers et couche matérielle Les programmes ( ceux composant Windows comme ceux fournis avec l'environnement ou alors les applications ) accèdent aux bibliothèques systèmes via une API ( Application Programming Interface ) composée d'environ 1000 fonctions distinctes. Les bibliothèques systèmes accèdent aux différents drivers via des appels internes spécifiques. Chaque composant système crée et gère un ensemble d'objets : ¤ Kernel est le composant de plus bas niveau : il gère les entrées / sorties ( accès fichiers ), la mémoire, le chargement des programmes et des DLL ainsi que leurs images mémoires, etc. ¤ User assure la gestion des fenêtres : création, positionnement à l'écran, messages. Il assure aussi la gestion des tâches ( car c'est lui qui gère les boucles d'événements ). Page VII. 6

L'environnement Windows ¤ GDI crée les ustensiles permettant de dessiner à l'écran ( brosses, pinceaux, icônes, curseurs, gestion des pixels, etc. ). Il constitue en fait l'interface d'affichage de Windows et permet l'affichage des données à l'écran .... ou sur l'imprimante. En interne User et GDI font souvent appel aux services de Kernel.





Dans le cadre d'une programmation multitâche ( sous Windows NT ou Windows 9x ) Kernel gère aussi les processus et les mécanismes de communication inter-processus. Compte tenu de l'ensemble des fonctions réalisées par Kernel, on peut considérer que ce dernier est un véritable noyau du système d'exploitation. Le programme Win.Com n'est en fait qu'un lanceur d'application qui vérifie la configuration du PC, choisit en conséquence le mode de fonctionnement le plus adapté, initialise le mode graphique adéquat, lance le logo Microsoft et charge le motif bitmap de fond d'écran. Il charge en mémoire les bibliothèques système.

7.32 : Notion de ressources systèmes Les bibliothèques systèmes utilisent chacune une zone mémoire spécifique pour y stocker les informations dont elles ont besoin pour gérer les différents objets qu'elles créent. Ces zones particulières sont appelées "ressources systèmes". Comme Windows utilise pour ses besoins propres une partie de ces zones mémoire, ces dernières ne sont jamais disponibles à 100 % pour assurer la gestion des applications ( en général il reste environ 80 % de ressources disponibles à l'issue du démarrage de Windows ).



Dans Windows 3.1 la taille cumulée de ces zones mémoires était très réduite parce que les zones mémoires facilement manipulables ne pouvaient pas excéder 64 Ko. De fait il y avait fréquemment pénurie de ressources système, impossibilité de lancer les applications et, souvent, plantage du système. Les choses se sont petits à petit améliorées avec Windows 95 et Windows 98... mais la gestion des ressources système reste un problème.

Ces ressources doivent être gérées avec attention, en particulier par le fait que Windows lui-même les gère très mal ( même si les choses ont été améliorées depuis Windows 3.1). Il faut prendre en considération les faits suivants :

-

Chaque fenêtre créée, lors de l'exécution d'une application, consomme environ 2 % des ressources allouées à User. Celles-ci ne sont pas rendues par le système lorsqu'on icônifie une fenêtre. Une fenêtre de groupe de programmes est aussi une fenêtre. Il est donc prudent de n'ouvrir ces fenêtres qu'en cas de besoin.

- L'application chargée en mémoire consomme aussi des ressources système. Il faut prendre en compte le fait que l'interface d'accueil de certaines applications est constituée par plusieurs fenêtres ( barre de menu, barres d'icônes, ligne d'état, fenêtres MDI, etc. ). Le nombre d'objets utilisés a aussi une influence immédiate sur la consommation des ressources. Page VII. 7

L'environnement Windows De fait les applications récentes, qui souffrent de "boutonite" aiguë, sont grosses consommatrices de ressources... ce qui peut amener au blocage de Windows même si la mémoire vive disponible semble largement suffisante au lancement et à l'exécution de l'application.



Il est possible de connaître le pourcentage de ressources disponibles à un moment donné en activant l'item "A propos .... " d'une application. Une boite de dialogue s'affiche alors. En cliquant sur le bouton "Infos systèmes" on obtient, entre autres, une information sur l'état des ressources GDI et User ( les plus sensibles ). A titre d'information GDI répertorie dans les ressources système des informations sur tous les objets utilisés dans une application. Cette gestion consommait, sous Windows 95, les ressources suivantes : Pinceau : 32 octets Police : environ 40 octets Palette : 28 octets Zone graphique : de 28 octets à plusieurs Ko De même User gère les objets placés sous sa responsabilité en consommant, par exemple, 20 octets par menu ( + 20 octets par item du menu ).



Lorsque Windows ne possède plus assez de ressources disponibles pour réaliser ce qui est demandé par l'application, son comportement devient aléatoire ( certaines ressources deviennent inaccessibles ) et cela peut finir par un plantage complet du système.

7.4 : L'environnement Windows 7.41 : Les fenêtres 7.411 / Généralités : On considère parfois Windows principalement comme un "gestionnaire de fenêtres". La notion de fenêtre ( "Window" ) est en effet capitale dans cet environnement : -

Une application est lancée dans une fenêtre qui lui est propre. Pour terminer l'application il faut fermer la fenêtre (et non simplement la réduire ou la cacher ). Les événements systèmes sont gérés au niveau de la fenêtre.

Une fenêtre est définie par : - Une zone rectangulaire permettant l'affichage ; - Une icône, utilisée quand on a "réduit" la fenêtre ; - Une barre de titre permettant, dans la plupart des cas, de déplacer la fenêtre ; - Des bordures permettant normalement le redimensionnement de la fenêtre ; - Un menu ; - Des pinceaux et des brosses pour colorier, dessiner ou écrire ; - etc. Une fenêtre peut être assimilée à un terminal virtuel dans lequel une application s'exécute. Windows peut gérer simultanément plusieurs fenêtres mais une seule est active à un moment donné.

Page VII. 8

L'environnement Windows



Plusieurs applications peuvent être en cours d'exécution, mais seule l'application dont la fenêtre est activée entretient un dialogue avec l'utilisateur.

7.412 / Caractéristiques générales d'une fenêtre :  Éléments fondamentaux d'une fenêtre : Une fenêtre se présente souvent sous la forme suivante : Bouton de fermeture Bouton de redimentionnement Bouton de réduction

Barre de titre

Bordures

Dans certains cas, à la suite d'un redimensionnement de la fenêtre par exemple, la surface interne de celle-ci ( appelée zone "client " ) n'est plus affichée intégralement. Windows met alors en place des ascenseurs ( un vertical et un horizontal ) permettant d'accéder aux zones de la fenêtre non affichées. On parle alors de scrolling.

Le fait de cliquer sur la flèche fait déplacer légèrement la zone client dans le sens souhaité.

Le fait de cliquer sur le bouton de déplacement fait déplacer rapidement la zone client dans le sens souhaité.

Le fait de cliquer dans l'ascenseur provoque des déplacements plus importants qu'avec le bouton.

Diverses possibilités de déplacements à l'aide de l'ascenseur. Ces différentes options sont programmables. Page VII. 9

L'environnement Windows

7.413 / Types de fenêtres : Il existe plusieurs types de fenêtres qui présentent néanmoins de nombreuses caractéristiques communes ( au niveau de leur gestion interne ) : ¤ Les fenêtres proprement dites : Ces fenêtres sont généralement dotées d'une barre de titre, de menus et d'une ou plusieurs barres d'icônes. Des "boutons systèmes" sont situés de part et d'autres de la barre de titre. Elles sont redimensionnables. Parmi ces fenêtres il y a la fenêtre principale de l'application.

¤ Les "boites de dialogues" : Ces fenêtres offrent des possibilités de dialogue interactif avec l'utilisateur. Elles sont généralement de petites tailles, ne disposent pas de menu. Elles sont dépourvues de boutons de redimensionnement et de bordures.

Exemple d'une boite de dialogue standard relativement complexe ( Il est possible de créer tout type de boites de dialogue ). Une boite de dialoguer ne peut pas, généralement, être redimensionnée. Notez que sur cet exemple il existe un bouton "Aide" dans la barre système. ¤ Les "messages d'avertissement" Sont des boites de dialogue rudimentaires, parfois dépourvues de barre de titre, et ne possédant ni "boutons systèmes" ni bordures. Elles ne sont pas redimensionnables.

Page VII. 10

L'environnement Windows

Une boite de message type : elle ne permet de réaliser que quelques actions, de surcroît standardisées. Une boite de message est normalement dépourvue de titre ( elle affiche le nom de l'application ).

7.414 / Fenêtre modale ou amodale : Les fenêtres s'affichent selon deux modes différents : le mode modal ou le mode amodal.  Mode modal : Dans ce mode, la fenêtre possède sa propre file d'événements. Lorsqu'elle est active, seuls les événements qui lui sont associés peuvent être pris en compte. Ce qui revient à dire que toute action exécutée en dehors de la surface occupée par la fenêtre ne sera pas prise en compte. Par exemple si une fenêtre fille d'une application s'affiche en mode modal, il faut au préalable la fermer pour accéder aux menus de l'application.

 Mode amodal : Les fenêtres amodales se partagent la même file d'événements. De ce fait des événements destinés à une autre fenêtre peuvent être pris en compte. Grâce à ce mode d'affichage on peut basculer d'une fenêtre active à une autre ( qui devient alors active ) en cliquant sur la surface de cette dernière.

En règle générale : - La fenêtre principale de l'application est amodale. Cela permet à l'utilisateur de basculer vers une autre application en cours d'exécution. - Les boites de dialogues fonctionnent la plupart du temps en mode modal. - Les boites de messages fonctionnent impérativement en mode modal.

Il faut bien comprendre que le fait qu'une fenêtre soit modale est une des rares possibilités laissées au programmeur pour diriger les actions de l'utilisateur : en l'enfermant dans une fenêtre modale ou les possibilités d'action sont réduites, il est plus facile de contrôler ses actions. En particulier il faut rendre modale toute fenêtre ou boite de dialogue qui permet d'accéder à des données importantes pour l'application. Si par exemple un utilisateur peut accéder à une table à partir de deux fenêtres ouvertes simultanément en mode amodal, on ne saura jamais quelle est la dernière donnée validée. L'intégrité du système est donc mise en cause. D'où la nécessité de rendre modal ce genre de fenêtre : une fois une action commencée sur une table elle est soit annulée soit confirmée mais au moins la situation finale est cohérente. Page VII. 11

L'environnement Windows Les boites de messages sont toujours modales ( n'importe comment le programmeur n'a pas le choix dans ce cas ) car le système a besoin impérativement d'une réponse précise pour continuer son exécution.

7.42 : Applications MDI ou SDI On distingue traditionnellement les applications fonctionnant en mode "simple" de celles fonctionnant en mode MDI ou en mode SDI.  Applications "simples" : Il s'agit d'applications qui ne sont composées que d'une fenêtre principale, constituant le cadre de l'application ( avec le cas échéant menus et barre d'icônes ), et, éventuellement, de boîtes de dialogue et de fenêtres de messages. Le bloc-notes de Windows fonctionne selon ce mode : lorsqu'un document est chargé, il n'est pas possible d'en charger un autre sans, au préalable, fermer le premier document.

 Applications MDI ( Multiple Document Interface ) : Ce type d'application gère plusieurs fenêtres filles ( ou fenêtres enfants ) qui sont des répliques d'un modèle unique : il est alors possible, par exemple, de réaliser plusieurs traitements de même nature en parallèle ( chacun dans une fenêtre fille particulière ). Les menus attachés à chaque fenêtre fille peuvent être distincts de celui de la fenêtre principale. L'ensemble des fenêtres filles ne peut pas dépasser l'espace alloué à la fenêtre principale de l'application : il y a clipping de la fenêtre fille lorsque, à la suite d'un déplacement, une partie de sa surface se retrouve à l'extérieur de la surface de la fenêtre mère ( néanmoins Windows continue à gérer la partie de la fenêtre ainsi effacée ). Les applications bureautiques ( traitements de texte, tableurs et logiciels de dessin ) sont souvent de ce type : il est alors possible de charger plusieurs documents et de travailler sur ces derniers.

 Applications SDI : Ce type d'application gère plusieurs fenêtres indépendantes les unes des autres ( si ce n'est qu'il y a encore une fenêtre de démarrage à partir de laquelle les autres fenêtres sont créées lorsque le besoin s'en fait sentir ). Les fenêtres peuvent donc "déborder" les unes des autres. Dans certains cas, la fenêtre principale est réduite à la barre des menus et / ou à celle des icônes. De ce fait les fenêtres filles donnent l'impression de "flotter" au-dessus d'une application étrangère sous-jacente ( voire du bureau de Windows ) : C++ Builder fonctionne selon ce mode et est grand générateur de fenêtres.

Page VII. 12

L'environnement Windows

Exemple d'application MDI avec fenêtres-filles clippées.

Le mode MDI est le mode qui a été privilégié par Windows 3.1. Le mode SDI est, quant à lui, le mode privilégié par Windows 9x. Une application qui aurait à gérer plusieurs fenêtres de même type peut cependant être créée en mode MDI.

7.5 : Programmation d'une application Windows 7.51 : Les différentes possibilités de programmation Programmer "Windows" est une chose réputée difficile qui nécessite beaucoup d'effort et d'attention de la part des programmeurs. Pour programmer une application fonctionnant dans l'environnement Windows il faut que celle-ci soit en mesure d'appeler les différentes fonctions faisant partie de l'API Windows. Il faut donc savoir comment appeler les différentes fonctions, comment gérer le mécanisme événementiel et comment gérer les différents composants d'une application.

Page VII. 13

L'environnement Windows

Heureusement, grâce aux nouveaux environnements de développement, le programmeur qui souhaite réaliser une application Windows dispose en fait de plusieurs méthode de programmation qu'il pourra utiliser en fonction de son expertise et des buts recherchés.  Utilisation du SDK ( Software Development Kit ) : C'est l'ensemble des objets et des fonctions ( plus d'un millier ) fournis par Microsoft pour créer directement des applications Windows. Les fonctions du SDK étant codées en langage C, c'est ce langage qui est utilisé pour le manipuler : les spécificités du C++ et de la P.O.O. n'entrent donc pas en ligne de compte. Pour réaliser une application Windows avec le SDK, il faut donc connaître les centaines de fonctions et de variables prédéfinies qui le composent et maîtriser intégralement le développement de l'application ( gestion des événements, création d'une fenêtre, etc. ).

 Utilisation de bibliothèques de classes : Face à la difficulté réelle d'utiliser le SDK, les principaux éditeurs de compilateurs fournissent des bibliothèques de classes et/ou de composants qui comportent un grand nombre d'objets permettant de réaliser plus rapidement des applications Windows importantes. Les principales bibliothèques de classes disponibles sont écrites en langage C++. Il s'agit de la bibliothèque OWL de Borland et de la bibliothèque MFC de Microsoft, incompatibles entre elles. La bibliothèque VCL de C++ Builder est quant à elle celle créée pour Delphi et est écrite avec le langage Object Pascal.

Ces bibliothèques prennent en charge plus ou moins complètement les principales difficultés de la programmation Windows ( gestion des événements, gestion des interfaces graphiques, etc. ) en "encapsulant" les appels aux fonctions du SDK dans des méthodes spécifiques contenues dans leurs classes. Lorsque l'on utilise une méthode d'une classe de la bibliothèque VCL, celle-ci, en interne, appelle directement la ou les fonctions adéquates du SDK selon des mécanismes complexes qui auraient été délicats à maîtriser avec le SDK.



Par contre certaines possibilités offertes par le SDK ne sont pas reprises par les bibliothèques de classes.

Le programmeur aura alors le choix entre :

- Utiliser les possibilités offertes par la bibliothèque fournie par l'environnement de développement (qui peut être enrichie par acquisitions externes ou téléchargements sur Internet ). Ce choix est préférable lorsqu'il s'agit d'utiliser des objets de haut niveau ( ex : fenêtres ou mécanismes d'accès aux bases de données ) ou des mécanismes complexes qui sont fortement encapsulés ( gestion des messages et diffusion de ceux-ci ). -

Utiliser directement des fonctions de l'API.

Page VII. 14

L'environnement Windows Ce choix peut être judicieux lorsque l'encapsulation est faible ( par exemple lorsque la fonction de la bibliothèque de classes se contente d'appeler la fonction correspondante de l'API ). Dans ce cas on améliore les performances de l'application en appelant directement la fonction du SDK car on élimine des appels inutiles de fonctions.

7.52 : Les différents types d'application Par delà les distinctions évoquées précédemment il est important de noter que les applications réalisées peuvent être classées en deux catégories très distinctes, en fonction de leur utilisation ( certaines applications font partie des deux catégories ), dont il est important de connaître les différences fondamentales :  Les applications prédéfinis.

utilisant

massivement

des boites de dialogue et des objets

Ces applications sont relativement aisées à réaliser surtout si l'on utilise les bibliothèques de composants prédéfinis fournies par l'environnement de développement. Tout le dialogue entre l'utilisateur et l'application est réalisé à travers des actions sur des boutons, des listes ou des zones de saisie. Les applications telles les gestionnaires de fichiers, les tableurs, plusieurs utilitaires et bien sûr les modules clients d'accès aux bases de données, font partie de cette catégorie.

 Les applications créant des objets à l'écran et modifiant leur interface graphique : Ces applications doivent gérer directement l'affichage graphique via des fonctions appelant GDI. L'utilisateur peut accéder à des composants et des classes spécifiques lui permettant de créer et de modifier des objets graphiques pendant l'exécution de l'application. Les différents logiciels graphiques et les modules graphiques des tableurs font partie de cette catégorie. La partie "gestion du texte" des traitements de texte peut être assimilée à cette catégorie.



Cette gestion "bas niveau" de l'interface graphique est plus complexe qu'il n'y paraît. GDI est en effet le composant système le plus complexe et les fonctions d'accès au GDI ne sont pas complètement encapsulées dans les bibliothèques de classes proposées. Dès qu'un programmeur souhaite personnaliser finement l'apparence graphique de son application il doit se résoudre, souvent, à utiliser directement les fonctions du SDK, avec toute la complexité de manipulation que cela entraîne.

Page VII. 15

L'environnement Windows

7.6 : Normes de programmation L'un des principaux attraits de l'interface Windows est que la plupart des applications mettent en œuvre les mêmes mécanismes de fonctionnement : - Les menus sont souvent classés dans le même ordre afin que l'utilisateur n'ait pas à chercher longtemps la fonctionnalité désirée. - Les boites de dialogues se manipulent de la même manière et présentent les mêmes séquences de boutons de contrôle.



Même si au début de l'ère Windows certaines applications ont proposé des interfaces "divergentes", aujourd'hui une application qui proposerait des menus et des boites de dialogues trop différentes serait condamné commercialement.

Imaginez une boite de dialogue ou le bouton "Fermer" serait placé à la place habituelle du bouton "OK"....... vous ne tarderez pas à ne plus utiliser l'application.

Quand on réalise une application Windows il y a donc lieu de connaître les principales normes retenues (mêmes si les évolutions sont incessantes ).

7.61 : Ordre des menus Toutes les applications Windows doivent positionner les menus selon un ordre précis (sauf cas d'applications vraiment particulières ). En fait seuls certains menus doivent être positionnés selon les normes, les autres étant spécifiques à l'application :  Le menu Fichier : Ce doit être le premier menu à partir de la gauche. Il comporte les rubriques permettant de manipuler les fichiers utilisés par l'application. Les rubriques imposées sont : Nouveau : Ouvrir : Fermer :

création d'un fichier ouverture d'un fichier existant. fermeture d'un fichier sans sortir de l'application.

Enregistrer : Enregistrer sous : Imprimer : Config. de l'imprimante. Quitter :

sauvegarde des données sur le disque. sauvegarde sous un autre nom. impression du document. quitter l'application.

Dans ce menu on peut insérer d'autres rubriques ( selon l'application ) et, éventuellement, en bas du menu, l'historique des derniers fichiers ouverts.

Page VII. 16

L'environnement Windows

 Le menu Edition : Ce menu, le deuxième sur la barre de menu, donne accès aux fonctions de gestion du presse-papiers (Copier | Couper | Coller ) ainsi que, le cas échéant, des fonctionnalités de recherche et de remplacement de texte. Il propose souvent une fonction permettant d'annuler la dernière action. Si cette fonctionnalité est proposée elle doit se situer en tête de la liste des éléments du menu.  Le menu Fenêtre : Ce menu, systématiquement l'avant dernier dans la barre des menus, permet de gérer les différentes fenêtres ouvertes ( dans le cas d'une application MDI ). Il permet de positionner les fenêtres ouvertes en cascade ou en mosaïque.  Le menu ? : Ce menu, s'il existe, est obligatoirement le dernier. Dans certains cas il est déplacé à l'extrême droite de la fenêtre. Il permet d'accéder à l'aide en ligne de l'application ( obligatoirement réalisée à l'aide d'un éditeur générant des fichiers texte au format '.RTF' et en utilisant un compilateur d'aide permettant de générer un fichier '.HLP' ).

Les autres menus, placés systématiquement entre les deux premiers et les deux derniers menus cités précédemment, sont spécifiques à l'application.



Les rubriques les plus utilisées des différents menus sont doublées par des boutons à icônes, placés dans une barre située normalement juste audessous de la barre de menus. Là aussi il y a lieu d'utiliser des icônes standardisées facilement interprétables. Ces mêmes rubriques sont souvent accessibles via des combinaisons de touches ("raccourcis clavier" ). Les combinaisons les plus connues sont elles aussi standardisées : Fichier | Ouvrir : Ctrl + 0 Edition | Copier : Ctrl + C etc.

7.62 : Les boutons des boites de dialogue Les boîtes de dialogue proposent généralement un jeu plus ou moins complet de boutons proposant des choix d'actions aux utilisateurs. Les boutons utilisés sont légendés : les légendes utilisées répondent à une standardisation de fait : Page VII. 17

L'environnement Windows

-

OK :

Ou 'Oui'. L'utilisateur valide les choix réalisés dans la boîte de dialogue. Sauf erreur détectée par l'application, l'effet et immédiat et la boîte est refermée.

-

Non :

-

Annuler :

Ou 'No'. L'utilisateur ne valide pas la proposition de la boîte de dialogue. La boite est fermée et l'application tient compte du choix de l'utilisateur. Ou 'Cancel'. Les choix réalisés ne sont pas pris en compte. La boîte de dialogue est fermée et l'application revient à la situation antérieure sans aucune modification.

Dans le cas où les trois boutons apparaissent, ils doivent respecter l'ordre de la figure ci-dessous :

Cette boite de dialogue, qui appartenait pourtant au panneau de configuration de Windows 3.1, n'est pas conforme : Le bouton 'OK' n'apparaît pas. C'est le bouton 'Annuler', qui se transforme en bouton 'Fermer' en cas de modification de la configuration, qui permet de valider les options.

7.63 : Contraintes systèmes  Niveaux de fenêtres :

Page VII. 18

L'environnement Windows Afin de ne pas gaspiller inutilement les ressources systèmes, et aussi dans le but de simplifier l'utilisation des applications, Windows impose qu'il n'y ait pas plus de deux niveaux de fenêtres filles dans une application ( à l'exclusion des boîtes de dialogue standardisées et des messages ).

 Économies de composants : Dans la mesure du possible il est souhaitable de n'utiliser que peu de types de composants ou d'objets système. GDI par exemple gère chaque police de caractères et chaque icône utilisée. Si l'application utilise 10 polices différentes la consommation sera plus importante que si tous les affichages sont réalisés avec 2 ou 3 polices différentes. De même il existe plusieurs types de boutons. Si on les utilise tous pour construire les interfaces, cela sera plus consommateur que si l'on se contente d'en utiliser deux types.

 Utilisation de composants complexes : Il faut aussi faire attention aux objets que l'on utilise pour construire une interface graphique moderne. Les tendances actuelles ( multifenêtrage, icônes, multiplication des boutons, etc. ) font que les applications actuelles sont plus gourmandes en ressources qu'autrefois ( et l'on ne parle pas de l'occupation mémoire ). Par exemple on utilise fréquemment un objet de type "onglet" ( Word en fait une grande consommation ). Si les objets déposés dans les différents feuillets de l'onglet ne sont pas trop complexes, cela peut aller. Mais si toute l'application est gérée au sein d'une seule fenêtre contenant un onglet, chaque feuillet comprenant plusieurs objets ( dont des objets d'accès aux bases de données, les plus gourmands ), la consommation en ressources systèmes peut devenir très importante. En effet l'onglet est considéré comme un seul objet et est chargé d'un seul bloc en mémoire avec tous les composants qu'il contient.

 Chargement en mémoire des différentes fenêtres : Il est possible de charger en mémoire toutes les fenêtres constituant une application lors du démarrage de l'application. Cette option peut être gourmande en ressources. Elle est en tous cas peu efficace, car certaines fenêtres peuvent ne jamais être utilisées pendant une session de travail, voire dangereuse. Il est donc généralement préférable de ne charger les fenêtres que lorsque le besoin s'en fait sentir, après une action particulière de l'utilisateur.  Découpage du programme en modules dynamiques : Les programmes graphiques ont souvent une taille très importante. Il est souhaitable de découper un programme un peu ambitieux en plusieurs modules chargeables dynamiquement ( DLL ).

Page VII. 19

L'environnement Windows

Être efficace : Il ne suffit pas de créer une interface graphique utilisant les dernières nouveautés proposées par les bibliothèques de classes ni même de respecter toutes les normes et standard pour qu'une application ait du succès. Encore faut-il que l'application soit réellement utilisable. Pour ce faire, il faut que chaque fenêtre et chaque boite de dialogue ne contienne que les composants utiles à un moment donné, et surtout qu'il n'y en ait pas trop : une fenêtre contenant trop de boutons, trop de zones de saisie, trop d'options devient inutilisable. La création d'une interface peut être très longue. Surtout que, qu'on le veuille ou non, l'esprit se satisfait inconsciemment de ce qui est ordonné : il faut donc aligner les boutons et les différents cadres, et cela finit par prendre du temps, si l'on veut que l'application soit "agrée" par les utilisateurs.

Page VII. 20

L'environnement Windows

Page VII. 21