Le minimum pour une fenêtre win32
Description
Ce source explique un peu une face "cachée" (Bien connue) de la VCL.
Les environement de developpement de C/C++ non RAD proposent généralement un type d'application "GUI" dans leur nouveau projet.
GUI signifie Graphical User Interface, c'est à dire dans notre cas une application windows classique non console.
Ce code est une simple une proposition de traduction qui est loin d'être la première, mais cette version à deux avantages :
Elle est abondament commentée.
Elle ne perd pas le code indispensable dans le code du reste d'une appli utile.
Les avantages par rapport à une utilisation classique de Delphi sont a priori inexistant, excepté un gain en taille conséquent :
362 Ko pour une appli utilisant la VCL.
15 Ko pour une appli de ce code.
(Sous Delphi 7)
Un inconvénient majeur étant que l'on ne puisse pas mettre en place les composants à la souris...
Un autre est la perte en portabilité du code vers Linux.
Le principe de ce type d'appli est simple, même si la VCL simplifie encore le travail :
La création d'une fenêtre ce fait en 2 étapes :
D'abord, il faut définir une classe de fenêtre et la signaler à windows.
On peut ensuite instancier des fenêtres de cette classe.
Pour ce qui est de l'execution de l'application à proprement parler (Application.Run), c'est à peine plus sioux.
Si les programmes ne bouclaient pas, ils se fermeraient en quelques secondes.
Donc il boucle sur quelque chose...
Ce quelque chose, c'est la récupération des messages envoyés par Windows à l'appli.
L'un des rôle de windows est en effet de dire à chaque appli tournant :
On as cliqué sur ta fiche numéro x à cet endroit.
Tu pourrais redessiner le contenu de ta fiche y ?
L'utilisateur est en train de redimenssionner ta fiche z.
Et on traite tous ces messages (qui arrivent en file) jusqu'à la réception d'un message ou Windows demande de fermer l'appli.
Les messages sont d'abord réceptionner au niveau de la boucle de traitement des messages de l'application, qui les distribue ensuite à ses différentes fiches, ou les traite elle même.
Tout ça permet de comprendre un peu mieux comment se fait techniquement la programmation évenementielle.
Cela explique aussi le gel des applis qui ne veulent pas se fermer quand on clique sur la crois par exemple :
Windows envoie le message de fermeture à l'appli, mais celle-ci executant un évènement très long (voir bouclant), elle ne boucle plus sur la réception de ses messages.
Le message de fermeture reste donc dans la file d'attente sans être traité...
Windows s'en aperçoit parfois, et propose alors à l'utilisateur une solution plus radicale : l'éradication pure et simple du processus.
C'est pour cela que certaines appli, sachant un traitement très long, regardent la file de messages de temps en temps en cours de celui-ci.
Sous Delphi, ça se fait très facilement via Application.ProcessMessages.
Les environement de developpement de C/C++ non RAD proposent généralement un type d'application "GUI" dans leur nouveau projet.
GUI signifie Graphical User Interface, c'est à dire dans notre cas une application windows classique non console.
Ce code est une simple une proposition de traduction qui est loin d'être la première, mais cette version à deux avantages :
Elle est abondament commentée.
Elle ne perd pas le code indispensable dans le code du reste d'une appli utile.
Les avantages par rapport à une utilisation classique de Delphi sont a priori inexistant, excepté un gain en taille conséquent :
362 Ko pour une appli utilisant la VCL.
15 Ko pour une appli de ce code.
(Sous Delphi 7)
Un inconvénient majeur étant que l'on ne puisse pas mettre en place les composants à la souris...
Un autre est la perte en portabilité du code vers Linux.
Le principe de ce type d'appli est simple, même si la VCL simplifie encore le travail :
La création d'une fenêtre ce fait en 2 étapes :
D'abord, il faut définir une classe de fenêtre et la signaler à windows.
On peut ensuite instancier des fenêtres de cette classe.
Pour ce qui est de l'execution de l'application à proprement parler (Application.Run), c'est à peine plus sioux.
Si les programmes ne bouclaient pas, ils se fermeraient en quelques secondes.
Donc il boucle sur quelque chose...
Ce quelque chose, c'est la récupération des messages envoyés par Windows à l'appli.
L'un des rôle de windows est en effet de dire à chaque appli tournant :
On as cliqué sur ta fiche numéro x à cet endroit.
Tu pourrais redessiner le contenu de ta fiche y ?
L'utilisateur est en train de redimenssionner ta fiche z.
Et on traite tous ces messages (qui arrivent en file) jusqu'à la réception d'un message ou Windows demande de fermer l'appli.
Les messages sont d'abord réceptionner au niveau de la boucle de traitement des messages de l'application, qui les distribue ensuite à ses différentes fiches, ou les traite elle même.
Tout ça permet de comprendre un peu mieux comment se fait techniquement la programmation évenementielle.
Cela explique aussi le gel des applis qui ne veulent pas se fermer quand on clique sur la crois par exemple :
Windows envoie le message de fermeture à l'appli, mais celle-ci executant un évènement très long (voir bouclant), elle ne boucle plus sur la réception de ses messages.
Le message de fermeture reste donc dans la file d'attente sans être traité...
Windows s'en aperçoit parfois, et propose alors à l'utilisateur une solution plus radicale : l'éradication pure et simple du processus.
C'est pour cela que certaines appli, sachant un traitement très long, regardent la file de messages de temps en temps en cours de celui-ci.
Sous Delphi, ça se fait très facilement via Application.ProcessMessages.
Codes Sources
A voir également
- Le minimum pour une fenêtre win32
- Taille minimum code barre - Forum Delphi / Pascal
- Fenetre sans cadre - Forum C / C++ / C++.NET
- Fenêtre plane ✓ - Forum Delphi / Pascal
- Interpréteur de commandes et console win32 ✓ - Forum C++ & C++ .NET
- Image fenêtre - Forum Python
Vous n'êtes pas encore membre ?
inscrivez-vous, c'est gratuit et ça prend moins d'une minute !
Les membres obtiennent plus de réponses que les utilisateurs anonymes.
Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.
Le fait d'être membre vous permet d'avoir des options supplémentaires.