[WinAPI] Dialog-Terminologie

[Krishty]

Ich notiere hier kurz, was ich zu Windows’ Terminologie bezüglich von Dialogen herausgefunden habe. Also:

• Dialog Box / Dialog: Ein Fenster, das einem anderen Fenster (meist dem Hauptfenster der Anwendung) untergeordnet ist, und mit einem Benutzer interagiert. Gute Beispiele findet man bei Dialog Boxes im MSDN. Obwohl die MSDN einen riesigen Satz an Funktionalität extra für Dialoge anbietet, scheinen sie letzten Endes als „normale“ Fenster realisiert – und nicht im Kernel verankert – zu sein.
   
• Control: Ein Objekt innerhalb eines Dialogs – z.B. ein Knopf oder ein Eingabefeld. Formal sind sogar die Texte, die dort stehen, Controls. Jedes Control ist als eigenes Fenster realisiert, das üblicherweise dem Dialog-Fenster untergeordnet ist.
   
• Item: Historisches Alias für Control. So ziemlich alle Funktionen, die mit Dialogen arbeiten, sind so benannt (z.B. GetDlgItemText()); die MSDN spricht aber in allen Erklärungen nur von Controls. Item bezeichnet heute wohl nur noch die Einträge von Menüs.
   
• modal Dialog: Das Programm kann nicht fortgesetzt werden bevor der Dialog abgearbeitet ist. Also die typische Fehlermeldung, die Ping macht, wenn man woanders klickt, und unbedingt erst weggeklickt werden muss.
   
• modeless Dialog: Dialog und Programm laufen nebenläufig weiter. (Sie sehen für den Benutzer nebenläufig aus; tatsächlich werden sie aber meist im selben Thread berechnet.)
   
• Dialog Procedure: Die Nachrichtenverarbeitung des Dialogs. Ähnlich der Hauptschleife jedes Fensters. Der Kniff ist: Da alle Dialoge gemeinsame Eigenschaften haben, und einfach zu schreiben sein sollen, verarbeitet die Dialogprozedur nur anpassbare Eigenschaften. Eigenschaften, die allen Dialogen gemeinsam sind, werden in der vordefinierten Fensterklasse des Dialogfensters verarbeitet, von dem aus die Dialogprozedur gefüttert wird. Daraus ergeben sich die Unterschiede (z.B. beim Rückgabewert).
   
• Dialog Message: Nachrichten, nicht von Windows selber kommen, sondern die die vorgefertigte Fensterprozedur des Dialogfensters extra für Dialoge an die Dialogprozeduren sendet (bspw. beim Navigieren durch Controls via TAB-Taste).
   
• Notification: Nachrichten, die der Dialog an das übergeordnete Fenster zurückgeschickt. So weit bin ich aber noch nicht.

Ergänzt ruhig oder stänkert rum, falls was falsch ist; ich trage hier in den nächsten Wochen weiter nach.

[Krishty]

Weil’s für’s Debugging nützlich ist: Diese Funktion bestimmt, ob es sich beim gegebenen Fenster-Handle um einen Dialog handelt:

    bool isDialog(
        HWND const suspect
    ) {
        if(FALSE == IsWindow(suspect)) {
            return false;
        }

        wchar_t className[8];
        GetClassNameW(suspect, className, 7);
        if(0 != wcscmp(className, L"#32770")) {
            return false;
        }

        return true;
    }

Als ich die Methode (Klassennamen auf #32770 testen) zum ersten Mal sah, dachte ich an einen üblen Hack. Stellt sich aber heraus, dass das dokumentiertes Verhalten ist: Siehe About Window Classes im MSDN.

[Krishty]

• button: Die Art von Control, die Windows für Knöpfe und Schalter verwendet. Der typische Ok-Knopf ist ein button, aber ebenso die kleinen Häkchen, die ihr in Dialogen setzen könnt.
   
• push button: Die häufigste Art von Knöpfen, nämlich der typische OK- oder Abbrechen-Knopf.
   
• default push button: Ein bestimmter Knopf innerhalb des Dialogs, der ausgelöst wird, wenn man von einem beliebigen Eingabefeld aus ENTER drückt. Es muss immer ein push button sein. Die MSDN behauptet, dass dafür automatisch der erste push button des Dialogs ausgewählt wird, aber das kann ich nicht bestätigen: Ist das erste Element eures Dialogs kein push button, kann GetLastError() irgendwann nach der Dialogerzeugung einen obskuren Element nicht gefunden-Fehler ausspucken. Ihr müsst den default push button explizit durch den Stil BS_DEFPUSHBUTTON markieren, oder nachträglich die DM_SETDEFID-Nachricht mit seiner ID an den Dialog senden. Vielleicht mache ich aber auch nur was falsch.