Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Bien sûr que ça va fonctionner mais c'était inutile dans ta demande d'origine qui ne concernait que de l'affichage. Mais si comme dans ton dernier exemple tu veux interagir avec la fenêtre, pas de miracle, il faut traiter les messages.Envoyé par Jlmat
Je n'ai personnellement aucune question
@ Andnotor, Oui, je me suis sans doute mal exprimé!
Paul:Andnotor:ce que je sais par contre, c'est que du coup le splashscreen n'est pas la fiche principale, et du coup soit tu as une fiche qui ne répond pas (pas de Application.ProcessMessages), soit tu as une fiche qui n'est pas la fenêtre principale et ça fait buguer la barre de Tâche Windows par exemple.Vous avez soulevé avec Paul la question que le Fait de créer Splash avant la Forme principale pour l'utilisateur (peut-être pas pour Delph!?) ça pouvait empêcher cette fenêtre de traiter les messages windows. C'est donc important que j'éclaircisse ce problème qui vient en complément de ma question d'origine car La fiche utilisateur doit pouvoir traiter tout évènement (c'était sous entendu). Mais j'ai peut-être mal interprété ce que vous avez dit.La boucle de messages n'est pas encore créée, l'application n'a aucune réponse à faire
C'est pour cette raison que j'essaye de voir si aussi bien dans la Form splash que dans celle de la fenêtre de l'utilisateur (Form1 ou FP dans mon exemple), le ProcessMessage fonctionnera correctement.
Ai-je bien compris? Parce que si le problème n'est pas là, alors je n'ai pas compris de quels types d'interception de messages, vous parliez...
Je programme en Lazarus 3.2.2 sous windows 10 pro
Ça ne sert à rien d'aller plus loin sans expliquer un minimum le concept.
Windows implémente une pile de messages globale.
Chaque thread qui requiert une gestion des messages va créer un pile qui lui est propre. Tout processus possède au minimum un thread et toute application graphique nécessite une gestion des messages.
Windows va transférer les messages de la pile globale dans les "sous-piles" en fonction de la cible.
L'application va vider cette pile dans une boucle infinie et transférer ces messages (dispatch) aux différentes fiches qui les feront éventuellement suivre au composants, etc.
La création de la pile du thread n'est pas automatique, c'est à l'application de la créer. Il n'y a pas de fonction particulière pour cela, elle est créée automatiquement au premier accès par GetMessage ou PeekMessage.
Dans Delphi, c'est TApplication.Run qui intègre la boucle de récupération des messages et c'est à ce moment-là que la pile du thread principal est effectivement créée. Avant cela, l'application n'a pas de gestionnaire de messages.
Mais une fenêtre n'a pas besoin de message pour se dessiner, WM_PAINT lui indique simplement que le rendu doit être rafraîchi suite à un autre événement : l'ordre d’empilement (Z-order) à changé, sa taille à changé, etc.
Vient maintenant TApplication.ProcessMessages. Cette méthode implémente également une boucle qui va lire les messages à l'instar de Run (mais sans gestionnaire d'exceptions) et son but premier est que lorsque la boucle Run est bloquée sur le traitement d'un événement (ex. un clique sur un bouton lançant un traitement long) d'autres messages puissent toujours être traités (ex. un clique sur un bouton d'annulation, une repeinture, etc.).
TApplication.Run et TApplication.ProcessMessages utilise la même méthode de récupération des messages : TApplication.ProcessMessage (au singulier). Dans les deux cas PeekMessage est invoqué et la pile est créée si elle n'existe pas encore. TApplication.ProcessMessages crée donc prématurément cette pile et tous les messages peuvent maintenant être récupérés. Mais cela implique aussi que TApplication.ProcessMessages soit appelé régulièrement (minimum toutes les 5 secondes) pour éviter un "L'application ne répond pas".
En résumé, si la SplashForm ne fait qu'afficher du texte un TForm.Update régulier suffit et Windows ne dira rien si le traitement est long (c'est la pile du thread qui est contrôlée), mais s'il faut de l'interaction TApplication.ProcessMessages est nécessaire et devra également être invoqué régulièrement sous peine de voir l'OS râler.
Il n'y a aucune contre-indication à l'un ou à l'autre, c'est fonction du besoin
Merci Andnotor pour ce rappel théorique!
Je programme en Lazarus 3.2.2 sous windows 10 pro
dès que tu crées une fenêtre (HWnd) il y a une file d'attente de message qui lui est attachée...et si personne ne fait appel à GetMessage(), DispatchMessage() celle-ci n'est pas traitée.
ensuite tu peux appeler Application.ProcessMessages avant d'appeler Application.Run, mais c'est un peu hasardeux et tu n'es pas à l'abris du rupture de comportement dans la VCL
Merci Paul pour ces précisions.
Je note tout ça dans un fichier... Du coup, je me replongerai sur la gestion des messages plus sérieusement. J'avais fait des récapitulations à une époque, mais je crois que ça fera l'objet d'un autre fil de discussion parce que j'aimerai bien finir celui là avec l'approche FMX proposée par Sergio...
Mon projet avance petit à petit!
Je programme en Lazarus 3.2.2 sous windows 10 pro
je ne suis absolument pas d'accord avec tes explications.Ça ne sert à rien d'aller plus loin sans expliquer un minimum le concept.
Windows implémente une pile de messages globale.
Chaque thread qui requiert une gestion des messages va créer un pile qui lui est propre. Tout processus possède au minimum un thread et toute application graphique nécessite une gestion des messages.
Windows va transférer les messages de la pile globale dans les "sous-piles" en fonction de la cible.
L'application va vider cette pile dans une boucle infinie et transférer ces messages (dispatch) aux différentes fiches qui les feront éventuellement suivre au composants, etc.
La création de la pile du thread n'est pas automatique, c'est à l'application de la créer. Il n'y a pas de fonction particulière pour cela, elle est créée automatiquement au premier accès par GetMessage ou PeekMessage.
Dans Delphi, c'est TApplication.Run qui intègre la boucle de récupération des messages et c'est à ce moment-là que la pile du thread principal est effectivement créée. Avant cela, l'application n'a pas de gestionnaire de messages.
Mais une fenêtre n'a pas besoin de message pour se dessiner, WM_PAINT lui indique simplement que le rendu doit être rafraîchi suite à un autre événement : l'ordre d’empilement (Z-order) à changé, sa taille à changé, etc.
Vient maintenant TApplication.ProcessMessages. Cette méthode implémente également une boucle qui va lire les messages à l'instar de Run (mais sans gestionnaire d'exceptions) et son but premier est que lorsque la boucle Run est bloquée sur le traitement d'un événement (ex. un clique sur un bouton lançant un traitement long) d'autres messages puissent toujours être traités (ex. un clique sur un bouton d'annulation, une repeinture, etc.).
TApplication.Run et TApplication.ProcessMessages utilise la même méthode de récupération des messages : TApplication.ProcessMessage (au singulier). Dans les deux cas PeekMessage est invoqué et la pile est créée si elle n'existe pas encore. TApplication.ProcessMessages crée donc prématurément cette pile et tous les messages peuvent maintenant être récupérés. Mais cela implique aussi que TApplication.ProcessMessages soit appelé régulièrement (minimum toutes les 5 secondes) pour éviter un "L'application ne répond pas".
En résumé, si la SplashForm ne fait qu'afficher du texte un TForm.Update régulier suffit et Windows ne dira rien si le traitement est long (c'est la pile du thread qui est contrôlée), mais s'il faut de l'interaction TApplication.ProcessMessages est nécessaire et devra également être invoqué régulièrement sous peine de voir l'OS râler.
Il n'y a aucune contre-indication à l'un ou à l'autre, c'est fonction du besoin
quand tu crées une fenêtre elle reçoit des tas de messages, ne serait-ce que parce que la souris passe devant (WM_MOUSEMOVE, WM_NCHITTEST et j'en passe)...et quand tu crées une fenêtre tu indiques explicitement la WndProc qui va traiter les messages, sauf que cette procédure n'est pas appelée que via le GetMessage/TranslateMessage qu'utilise Application.ProcessMessage...Car c'est bien dans le thread principal que sont traités tous les messages de l'application, il faut donc que le Thread principal demande explicitement le traitement des messages en attente.
Update (qui appelle UpdateWindow) est une exception car Windows va invoquer directement la WndProc avec le message WM_PAINT sans passer par la pile de messages....donc oui ça actualise la fenêtre, mais ça ne traite pas pour autant les messages en attente.
Mon explication est quelque peu foireuse je le reconnais. Vous pouvez
C'est un choix ! WS_EX_NOACTIVATE/WS_EX_TRANSPARENT permettent de limiter cela.
Ben oui mais en attendant Run, on peut l'aider un peu
Ça n'a rien d'exceptionnel, c'est le principe de SendMessage.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager