Salut,
Je voudrais savoir s'il est possible d'empêcher une fenêtre de se fermer (ou de se detruire) lorsque l'on clique sur la croix de cette dernière.
Merci.
Salut,
Je voudrais savoir s'il est possible d'empêcher une fenêtre de se fermer (ou de se detruire) lorsque l'on clique sur la croix de cette dernière.
Merci.
Bien sûr.
C'est ce qui se passe si tu tentes de fermer un programme avec des informations non-enregistrées...
La croix ne fait qu'envoyer un message WM_SYSCOMMAND(SC_CLOSE) (sauf dans une boîte de dialogue, où il est converti en WM_COMMAND(IDCANCEL) avant de parvenir à la DialogProc)...
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Merci![]()
Et comment empêcher la fenêtre de se fermer ? Car j'ai eu beau à essayer des return au niveau de WndProc à la reception de ce message, la fenêtre se ferme toujours !
Salut, c'est «WM_CLOSE» que tu dois utiliser dans ton «switch».
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
On ne connait pas l'étendue de ces capacités et la gestion de «WM_CLOSE» est ce qu’il a de plus facile à mettre en œuvre. N'oublions pas qu'il reste la possibilité de définir le style de la fenêtre avec «CS_NOCLOSE», ce qui bien entendu ne désactive pas «ALT-F4».
En ce qui concerne «WM_SYSCOMMAND» il faut non seulement faire la capture et comme tu le précises faire un filtrage (& 0xFFF0) pour identifier «SC_CLOSE».
Les résultats sont les mêmes, seul le niveau d'interception change.
Voila, avec CS_NOCLOSE ça marche nikel
Merci pour votre aide.
En fait, c'est surtout parce que j'aime garder des options sous la main. Si je veux bloquer seulement l'interface utilisateur, j'utilise WM_SYSCOMMAND, comme ça, un programme garde la possibilité de faire fermer la fenêtre en envoyant WM_CLOSE.
Si on veut empêcher à tout prix la fenêtre d'être fermée de l'extérieur (sauf assassinat du processus), on intercepte WM_CLOSE.
Mon problème en fait, c'est qu'intercepter WM_CLOSE supprime tout moyen de fermer la fenêtre depuis un autre thread du même processus. C'est pourquoi je préférais bloquer seulement la croix, et non pas le vrai message de fermeture.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Oui, ça se défend, mais dans ce cas autant désactiver le bouton de fermeture directement dans l'interface, au moins l'utilisateur en est averti.
En plus dans «WM_CLOSE» rien ne t'interdit d'y définir tes propres conditions pour autoriser ou non la fermeture de l'application, que ce soit pour un thread particulier ou un utilisateur.
Par contre, moi ce qui m'embête avec «WM_SYSCOMMAND», non seulement il constitue a lui seul de nombreux appels, mais en plus il englobe une quantité importante de paramètres de message, ce qui peut ce traduire par une certaine lourdeur lors de sa gestion, mais peut être qu'un profiler donnerait une vision un peu plus objective.
Partager