Dans une application fenêtrée je teste bien sûr les éventuels échecs des
fonctions et s'il y a échec je sorts avec une MessageBox, comme ceci :
/* récupération d'un handle sur l'écran entier */
if((hEcran = GetDC(NULL)) == NULL) {
MessageBox(NULL, "Echec de GetDC pour l'écran.\nFin de
l'application.", "Erreur !", MB_OK|MB_ICONERROR);
exit(EXIT_FAILURE);
}
Mais je me demande si c'est correct comme sortie?
Ne vaudrait-il pas mieux qu'un clic sur le bouton "OK" de ma MessageBox
envoie un message WM_CLOSE (ou quelque chose comme ça), à la fenêtre
principale du programme?
D'autre part, dans mon code, je me demande pourquoi l'instruction
exit(EXIT_FAILURE);
n'est effectuée QU'APRES un clic sur le bouton "OK", car je n'ai pas de
boucle de message (et tout ce qui va avec) pour cette MessageBox.
C'est étonnant...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
lgloub
> Mais je me demande si c'est correct comme sortie? Ne vaudrait-il pas mieux qu'un clic sur le bouton "OK" de ma MessageBox envoie un message WM_CLOSE (ou quelque chose comme ça), à la fenêtre principale du programme?
MessageBox retourne 0 en cas d'erreur de création de la fenêtre, ou ID_ABORT, ID_CANCEL, IDNO, etc. suivant le bouton clické. Rien ne t'empêche d'envoyer un message WM_CLOSE à ta fenêtre sur ID_OK. Mais tu peux aussi mettre le code que tu as WM_CLOSE à la suite.
D'autre part, dans mon code, je me demande pourquoi l'instruction exit(EXIT_FAILURE); n'est effectuée QU'APRES un clic sur le bouton "OK", car je n'ai pas de boucle de message (et tout ce qui va avec) pour cette MessageBox. C'est étonnant...
Un appel à MessageBox ne retourne qu'après sa fermeture.
> Mais je me demande si c'est correct comme sortie?
Ne vaudrait-il pas mieux qu'un clic sur le bouton "OK" de ma MessageBox
envoie un message WM_CLOSE (ou quelque chose comme ça), à la fenêtre
principale du programme?
MessageBox retourne 0 en cas d'erreur de création de la fenêtre, ou
ID_ABORT, ID_CANCEL, IDNO, etc. suivant le bouton clické.
Rien ne t'empêche d'envoyer un message WM_CLOSE à ta fenêtre sur ID_OK.
Mais tu peux aussi mettre le code que tu as WM_CLOSE à la suite.
D'autre part, dans mon code, je me demande pourquoi l'instruction
exit(EXIT_FAILURE);
n'est effectuée QU'APRES un clic sur le bouton "OK", car je n'ai pas de
boucle de message (et tout ce qui va avec) pour cette MessageBox.
C'est étonnant...
Un appel à MessageBox ne retourne qu'après sa fermeture.
> Mais je me demande si c'est correct comme sortie? Ne vaudrait-il pas mieux qu'un clic sur le bouton "OK" de ma MessageBox envoie un message WM_CLOSE (ou quelque chose comme ça), à la fenêtre principale du programme?
MessageBox retourne 0 en cas d'erreur de création de la fenêtre, ou ID_ABORT, ID_CANCEL, IDNO, etc. suivant le bouton clické. Rien ne t'empêche d'envoyer un message WM_CLOSE à ta fenêtre sur ID_OK. Mais tu peux aussi mettre le code que tu as WM_CLOSE à la suite.
D'autre part, dans mon code, je me demande pourquoi l'instruction exit(EXIT_FAILURE); n'est effectuée QU'APRES un clic sur le bouton "OK", car je n'ai pas de boucle de message (et tout ce qui va avec) pour cette MessageBox. C'est étonnant...
Un appel à MessageBox ne retourne qu'après sa fermeture.
Ambassadeur Kosh
dans ce cas, j'aurais utilisé une exception. ça evite de prendre en charge partout l'affichage du message, ça évite les rupture de sequences compliquée, et d'avoir a gérer par return de valeur d'erreur la "remontée" des états. (try catch throw font ça tres bien). et en plus, ça rend les choses claires et lisibles.
quant à savoir si WM_CLOSE doit être lancé ou pas, cela ne dépend que de ton appli. officiellement, une sortie propre est plus plaisante. mais bon...
dans ce cas, j'aurais utilisé une exception.
ça evite de prendre en charge partout l'affichage du message, ça évite les
rupture de sequences compliquée, et d'avoir a gérer par return de valeur
d'erreur la "remontée" des états. (try catch throw font ça tres bien). et en
plus, ça rend les choses claires et lisibles.
quant à savoir si WM_CLOSE doit être lancé ou pas, cela ne dépend que de ton
appli.
officiellement, une sortie propre est plus plaisante. mais bon...
dans ce cas, j'aurais utilisé une exception. ça evite de prendre en charge partout l'affichage du message, ça évite les rupture de sequences compliquée, et d'avoir a gérer par return de valeur d'erreur la "remontée" des états. (try catch throw font ça tres bien). et en plus, ça rend les choses claires et lisibles.
quant à savoir si WM_CLOSE doit être lancé ou pas, cela ne dépend que de ton appli. officiellement, une sortie propre est plus plaisante. mais bon...
