guter stil zu RegisterClass und CreateWindow
-
hallo
sollte man zu jedem fenster eine eigene klasse definieren ?
oder eine registerierte fensterklasse für so viele fenster wie möglich nehmen ?
ich brauch ca. 10 verschiedene fenster die alle was anderes machen bzw. anzeigen, die parameter für WNDCLASS sind aber immer die selben.für jedes fenster eine klasse registrieren ? oder nur einmal und dann für jedes fenster verwenden ?
Meep Meep
-
Eine Fensterklasse definiert eine bestimmte Art eines Fensters. Wenn du also mehrere Fenster einer bestimmten Art hast (z.B. Eingabeboxen, ...), solltest du dieselbe klasse benutzen. (Vergleiche mit der Art von Klassen die du vlt. aus C++ kennst).
-
Mit der Fensterklasse ist auch die Fensterprozedur verbunden.
Je nach Technik, die Du anwendest kann die natürlich virtualsiert werden.Wenn Du also klassich C in der Windows API anwendest wirst Du wohl für jedes Fenster eine eigene Klasse benötigen, außer es ist eine Stanmdardklasse.
In der MFC ist das durch die Ableitung der Fensterklassen zum Beispiel nicht nötig. Dort wird nur unterschieden zwischen Icon, Hintergrund, Menü etc.
-
Du kannst auch eine Fensterklasse für alles nehmen, die auf eine Standard-Prozedur verweist. Dann nutzt du einfach nach Bedarf SetWindowSubclass: https://msdn.microsoft.com/en-us/library/windows/desktop/bb762102%28v=vs.85%29.aspx. Das ist das gleiche Schema, mit der auch die Standard-Controls angepasst werden können. Mir fällt außerdem auch kein Member der WNDCLASS/EX-Struktur ein, was sich nachträglich nicht ändern ließe.
Andererseits reicht mir persönlich die Registrierung jeder einelnen Fenster-Klasse in kleinen Projekten aus (bis zu fünf Fenstern). Wenn sich nichts an den Parametern der WNDCLASSEX-Struktur ändert, wird für jede Klasse das gleiche Objekt genommen (nur mit anderen Werten bei lpfnWndProc und bei lpszClassName).
Für MDI-Anwendungen bspw. würde ich aber eine Fensterklasse für die Kindfenster nehmen und nach Bedarf alles weitere anpassen.
-
Martin Richter schrieb:
Mit der Fensterklasse ist auch die Fensterprozedur verbunden.
Je nach Technik, die Du anwendest kann die natürlich virtualsiert werden.Wenn Du also klassich C in der Windows API anwendest wirst Du wohl für jedes Fenster eine eigene Klasse benötigen, außer es ist eine Stanmdardklasse.
In der MFC ist das durch die Ableitung der Fensterklassen zum Beispiel nicht nötig. Dort wird nur unterschieden zwischen Icon, Hintergrund, Menü etc.
ich verwende eine basisklasse die die winproc kapselt und eine virtuelle funktion aufruft. von der klasse leite ich alle anderen ab.
sind die daten der WNDCLASS (icon, cursor usw) mit statischen daten einer C++-klasse vergleichbar ? oder kann ich die dann für jedes erzeugte fenster nachträglich individuell aendern ?
Meep Meep
-
Fake oder Echt schrieb:
Mir fällt außerdem auch kein Member der WNDCLASS/EX-Struktur ein, was sich nachträglich nicht ändern ließe.
-
Fake oder Echt schrieb:
Fake oder Echt schrieb:
Mir fällt außerdem auch kein Member der WNDCLASS/EX-Struktur ein, was sich nachträglich nicht ändern ließe.
Ich kann da jetzt die Antwort drin nicht finden.
Fake oder Echt schrieb:
Du kannst auch eine Fensterklasse für alles nehmen, die auf eine Standard-Prozedur verweist. Dann nutzt du einfach nach Bedarf SetWindowSubclass: https://msdn.microsoft.com/en-us/library/windows/desktop/bb762102%28v=vs.85%29.aspx.
Jo, das funktioniert schön so lange man WM_CREATE & Co nicht fensterspezifisch behandeln muss.
@Meep Meep
Die Window-Class-Member (SetClassWord/Long/LongPtr, GetClassWord/Long/LongPtr) gehören der Klasse, sind also quasi "static" Member.Etwas speziell ist dabei z.B. GCL_WNDPROC, da sich Änderungen an der Window-Proc erst beim Erstellen von neuen Fenstern auswirken (GCL_WNDPROC wird beim Erstellen des Fensters nach GWL_WNDPROC kopiert, und danach nur mehr GWL_WNDPROC verwendet).
non-static Member wären dagegen alles worauf man mit SetWindowWord/Long/LongPtr, GetWindowWord/Long/LongPtr zugreift.
-
hustbaer schrieb:
Fake oder Echt schrieb:
Fake oder Echt schrieb:
Mir fällt außerdem auch kein Member der WNDCLASS/EX-Struktur ein, was sich nachträglich nicht ändern ließe.
Ich kann da jetzt die Antwort drin nicht finden.
Abgesehen davon, dass du die Antwort gegeben hast, kann man sie auch in der MSDN in der Nähe von WNDCLASS/EX finden. Das gehört alles zur Window Class Reference. Hinweise auf Lösungen zu geben, auf die man ohne es zu wissen nicht (einfach) kommen kann, sehe ich ein. Mein Eigenzitat sollte nochmal in Richtung MSDN weisen (nach dem Motto: WNDCLASS/EX-Struktur! Ganz wichtig! Gucken, was man da so zu findet!), das war augenscheinlich nicht deutlich.
hustbaer schrieb:
Jo, das funktioniert schön so lange man WM_CREATE & Co nicht fensterspezifisch behandeln muss.
[...]
Etwas speziell ist dabei z.B. GCL_WNDPROC, da sich Änderungen an der Window-Proc erst beim Erstellen von neuen Fenstern auswirken (GCL_WNDPROC wird beim Erstellen des Fensters nach GWL_WNDPROC kopiert, und danach nur mehr GWL_WNDPROC verwendet).Set-/Get-/RemoveWindowSubclass sind Helper-Funktionen, die auch genutzt werden sollten. Das hat sogar auch Gründe, man mag es kaum glauben. Ansonsten kann man nämlich:
1. die Fenster Prozedur nur einmal ersetzen,
2. die Subclass nur recht schwer wieder entfernen,
3. nur ineffizient extra Daten zuordnen (user data) und
4. um die nächste Prozedur in der Reihenfolge der Fenster-Prozeduren aufzurufen, genügt es nicht, die Alte zu casten und dann aufzurufen, sondern man muss CallWindowProc aufrufen.Allerdings ist SetWindowSubclass/usw. erst ab ComCtl32.dll Version 6 (also WinXP aufwärts) verfügbar.
