Professional Documents
Culture Documents
7. Programmation événementielle
et environnement Windows
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 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 pseudo-
graphique, 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.
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.
Page VII. 2
L'environnement Windows
¤ Ils mettent en œuvre des mécanismes plus élaborés permettant de lier les
applications entre elles.
¤ 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.
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.
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 sous-
programmes 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.
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 ).
Page VII. 4
L'environnement Windows
Page VII. 5
L'environnement Windows
Utilitaires"système"
"système" Applications
Utilitaires Applications
GDI User
GDI User
Kernel
Kernel
¤ 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.
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.
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 :
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.
Page VII. 7
L'environnement Windows
- 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 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
Bouton de fermeture
Bouton de
redimentionnement
Bouton de réduction
Barre de titre
Bordures
Page VII. 9
L'environnement Windows
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 ).
Les fenêtres s'affichent selon deux modes différents : le mode modal ou le mode
amodal.
Mode modal :
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 :
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
Applications "simples" :
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 ).
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
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.
Page VII. 13
L'environnement Windows
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. ).
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.
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 ).
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 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.
Page VII. 15
L'environnement Windows
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.
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 ).
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.
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 au-
dessous de la barre de menus. Là aussi il y a lieu d'utiliser des icônes
standardisées facilement interprétables.
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
Dans le cas où les trois boutons apparaissent, ils doivent respecter l'ordre de la figure
ci-dessous :
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 :
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.
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 ).
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.
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