Frage

Ich bin also in jeder Hinsicht ein absoluter Anfänger Windows entsprechende Programmierung.Ich habe damit herumgespielt Windows API und bin auf ein paar Beispiele für die Initialisierung von Erstellungsfenstern usw. gestoßen.

Ein Beispiel erstellt ein reguläres Fenster (ich habe einen Teil des Codes abgekürzt):

int WINAPI WinMain( [...] )
{

    [...]

    // Windows Class setup
    wndClass.cbSize = sizeof( wndClass );
    wndClass.style  = CS_HREDRAW | CS_VREDRAW;
    [...]    

    // Register class
    RegisterClassEx( &wndClass );

    // Create window
    hWnd = CreateWindow( szAppName, "Win32 App",
                         WS_OVERLAPPEDWINDOW,
                         0, 0, 512, 384,
                         NULL, NULL, hInstance, NULL );
    [...]
}

Das zweite Beispiel erstellt ein Dialogfeld (keine Abkürzungen außer den WinMain-Argumenten):

int WINAPI WinMain( [...] )
{
    // Create dialog box
    DialogBox(hInstance, 
              MAKEINTRESOURCE(IDD_MAIN_DLG), 
              NULL, 
              (DLGPROC)DialogProc);
}

Das zweite Beispiel enthält keinen Aufruf der Registerfunktion.Es erstellt lediglich die DialogBox mit dem angehängten DialogProc-Prozess.

Das funktioniert gut, aber ich frage mich, ob es einen Vorteil hat, die Fensterklasse zu registrieren und dann das Dialogfeld zu erstellen (falls dies überhaupt möglich ist).

War es hilfreich?

Lösung

Sie müssen kein Dialogfeld registrieren.

Dialogfelder sind vordefiniert, sodass (wie Sie bemerkt haben) beim Erstellen eines Dialogfelds kein Verweis auf eine Fensterklasse vorhanden ist.Wenn Sie mehr Kontrolle über einen Dialog wünschen (wie Sie ihn erhalten, wenn Sie Ihre eigene Fensterklasse erstellen), würden Sie den Dialog in eine Unterklasse unterteilen, bei der es sich um eine Methode handelt, mit der Sie die Fensterprozedur „Dialoge“ durch Ihre eigene ersetzen.Wenn Ihre Prozedur aufgerufen wird, ändern Sie das Verhalten des Dialogfensters;Sie können dann die ursprüngliche Fensterprozedur aufrufen oder auch nicht, je nachdem, was Sie tun möchten.

Andere Tipps

Es ist schon eine Weile her, dass ich das getan habe, aber IIRC, der erste Fall ist die dynamische Erstellung eines Dialogs aus einer In-Memory-Vorlage.Das zweite Beispiel betrifft den weitaus häufigeren Fall der Erstellung eines Dialogs mithilfe einer Ressource.Die dynamischen Dialoge in Win32 waren ziemlich komplex, aber sie ermöglichten es Ihnen, eine echte datengesteuerte Schnittstelle zu erstellen und Probleme mit der Bündelung von Ressourcen mit DLLs zu vermeiden.

Was den Grund für die Verwendung von Win32 betrifft: Wenn Sie eine Windows-App benötigen und nicht auf MFC oder die .NET-Laufzeitumgebung angewiesen sein möchten, dann verwenden Sie diese.

Dies hängt nur am Rande mit der Frage zusammen, aber wenn Sie neu in der Windows-Programmierung sind, warum verwenden Sie dann Win32?Sofern nicht viel Low-End-Code vorhanden ist (der ohnehin von der GUI getrennt sein sollte), ist es wahrscheinlich sinnvoller, .NET zu verwenden, was auch weitaus weniger Kopfverletzungen verursachen sollte.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top