Jeder MFC Entwickler kennt AfxMessageBox. In der Klasse CWnd finden wir auch die Memberfunktion CWnd::MessageBox.
Mancher Entwickler wird sich nun fragen: Wann nehme ich denn nun was?
Kurze Antwort: Meide CWnd::MessageBox und nutze immer AfxMessageBox ❗
Lange Antwort:
CWnd::MessageBox ist einfach nur ein direkter Wrapper für Windows API Funktion MessageBox.
Der Grund warum man AfxMessageBox verwenden sollte liegt darin was AfxMessageBox einfach noch mehr leistet:
- AfxMessageBox benutzt die virtuelle Funktion CWinApp::DoMessageBox. Damit kann man zentral eine andere Behandlung für Fehlermeldungen einbauen.
- AfxMessageBox sorgt dafür, dass OLE Controls benachrichtigt werden, dass Ihre nicht modalen Dialoge nun deaktiviert werden müssen. Es wäre ja ziemlich heftig, wenn man solche Dialoge trotz aktiver MessageBox noch benutzen könnte. (siehe CWinApp::DoEnableModeless und Implementierung von CWnd::GetSafeOwner)
- CWnd::MessageBox benutzt das aktuelle Fensterhandle aus dem es aufgerufen wird als Parent-Handle für die API Funktion MessageBox. Die wenigsten Entwickler kennen, lesen oder beachten den netten Zusatz in der MessageBox Doku:
If you create a message box while a dialog box is present, use the handle of the dialog box as the hWnd parameter. The hWnd parameter should not identify a child window, such as a control in a dialog box.
Es ist also gerade zulässig CWnd::MessageBox aufzurufen, denn oft genug haben wir es mit Child-Windows zu tun.
Netterweise beachtet AfxMessageBox genau das. Es ermittelt das aktuelle aktive Top-Level Fenster und setzt es intern für den Aufruf von MessageBox.
Das wird auch ganz besonders wichtig, wenn man evtl. mehrere UI Threads hat. AfxMessageBox verwendet automatisch den richtigen. CWnd::MessageBox verwendet den aktuellen Thread aber evtl. als Fenster das Fenster-Handle aus einem anderen Threads. - CWnd:MessageBox hat keine Implementierung für die F1-Taste und die Hilfeimplementierung der MFC.
- Ich muss mich nicht um den Titel der MessageBox kümmern, denn AfxMessageBox benutzt den hinterlegten Applikationsnamen (CWinApp::m_pszAppName) der in der MFC hinterlegt und definiert wurde.
- Netterweise setzt AfxMessageBox passende Icons wenn nur die Reaktionsform definiert wird, also kein Icon. (MB_OK und MB_OKCANCEL benutzt MB_ICONEXCLAMATION, MB_YESNO und MB_YESNOCANCEL benutzt MB_ICONQUESTION).
HTH
Kennst Du einen Trick, AfxMessageBox() dazu zu bringen, KEIN Icon anzuzeigen?
Nicht jede Message braucht ein Icon und laut Vista UX Guide sollen Icons ohnehin eher sparsam eingesetzt werden.
Das ist für mich bisher der einzige Grund, ab und an doch CWnd::MessageBox() zu verwenden.
Ich gehe nicht konform mit Deiner Begründung.
Nach meiner Meinung sollte aufgrund des Widererkennungswertes jede MessageBox ein Icon haben!
Frage, Warnung, Information!
Ansonsten könntest Du mal MB_USERICON versuchen. Ich vermute dann erscheint kein Icon, obwohl diese ID nur für MessageBoxEx gedacht ist wird das auch bei AfxMessageBox funktionieren.
Danke, MB_USERICON scheint zu funktionieren.
Einige gute Argumente dafür, in bestimmten Situationen auf die Standard-Icons zu verzichten, finden sich hier:
http://msdn.microsoft.com/en-us/library/aa511277.aspx
Zitat: „While severity isn’t a consideration when choosing among the error, warning, and information icons, severity is a factor in determining if a standard icon should be used at all.“
Ich kann dieser UI Richtlinie nicht mehr folgen. Vor allem ändert sich das jedesmal wieder.
Alleine dieses Wort „severity“… severe bringt mich sofort in Richtung MB_ICONWARNING!
In dem angeführten Beispiel (ohne Icon) mit dem Wertebereich empfinde ich die Meldung, dass ein Wert außerhalb des Wertebereiches liegt als nützlich.
Für mich wäre das MB_ICONINFORMATION! Denn es ist eine nützliche Information 😉
Ansonsten: MB_USERICON trickst einfach nur den MFC Code aus…