DialogBox als Hauptfenster
-
@rT!f@Ct schrieb:
wenn du dir deine eigenen klassen auf basis der WinApi erstellst, ist da gar nix mehr kompliziert...
dein handlungsspielraum ist nur größer fals aus dem kleinen prog, doch was größeres werden sollte.
häh aber mein dialog braucht nur 2 knöppe artifakt. was soll ich dann da größeres draus mache?? häh..
-
Die Frage ist doch schon beantwortet: Solange Dein Dialog tut, was Du willst, und der Funktionsumfang Deinen Anforderungen genügt, spricht nichts gegen die Dialog-Methode.
Eigene Fensterklassen sind halt flexibler und bei größeren Projekten schneller erstellt. Mehr ist's nicht.
Tatache ist nur: Das Zusammenklicken im Resourcen-Editor und das Ausfüllen einer WNDCLASSEX-Struktur brauchen meiner Ansicht nach die gleiche Zeit. Und eine CALLBACK-Funktion brauchst Du auch in beiden Fällen. Ich sehe da also keinen großen Unterschied.
-
ok danke, und noch was anderes ich hab mit meinem Kollegen drüber geredet und er meint dass es zwar geht aber sinnlos wäre, da man WM_PAINT nicht in DialogBox benutzen darf. Wieder nur blödsinn?
-
rofl dein kollege ist ein b00n
-
in diesem Thread wird aber folgendes von Martin Richter geschrieben:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-244816-and-highlight-is-animatewindow.html"Allerdings ist es absoluter Unfud in einer DialogProc WM_PAINT zu behandeln!
Technisch unmöglich. Eine DialogProc ist eben keine WndProc."
-
Aber mit CreateWindow() muss man dann doch auch alle Controls manuell im Code erstellen, da wird man doch dumm bei.
-
es kann uns wohl nur Martin Richter sagen, was er damit meinte.
-
lol0r@lol0r schrieb:
Aber mit CreateWindow() muss man dann doch auch alle Controls manuell im Code erstellen, da wird man doch dumm bei
wenn du jedesmal wieder von vorne anfängst, kann ich deine meinung durchaus verstehn.
aber aus diesem grund gibt es ja zum beispiel klassen und die vererbung.
wenn du es geschickt anstellst, erstellst du dir eine klasse die die allgemeinen fensterfunktionen verwaltet. unteranderem auch CreateWindow, CreateWindowEx...
diese klasse vererbst du dann an eine klasse die speziell auf das jeweilige kontrol zugeschnitten ist.
ab diesen zeitpunkt hast du dann mit einer einzigen funktion ein control erstellt
-
Ja, und das genaue arritieren der Controls, damit es nach was aussieht? Per Hand, genau, bei einer komplexen UI... have fun!
Ich meine: Entweder Dialog Editor oder besser: UI System selbst schreiben (Ownerdrawn, Editor, ..)
-
Ich weiß nicht was Euch an meiner Äußerung bzgl. DalogProc und WndProc interessiert.
1. Kann man einen Dialog als Child Window in jedem Fenster hosten.
2. WM_PAINT kann nur einmal behandelt werden und dies geschieht in der WindowProc. Man kann WM_PAINT nicht einmal vernünftig subclassen durch die BeginPaint/EndPaint Problematik.
-
Martin es gibt aber keine WindowProc weil der Dialog das einzige Fenster in der Anwendung ist. Dann ist WM_PAINT zu bearbeiten ok oder?
-
wiexec schrieb:
Martin es gibt aber keine WindowProc weil der Dialog das einzige Fenster in der Anwendung ist. Dann ist WM_PAINT zu bearbeiten ok oder?
Nein! Dann muss man den Dialog subclassen, WM_PAINT selber behandeln und die Standard WndProc nicht aufrufen.
-
verstehe ich nicht, es gibt keine standard Window Proc da der Dialog das einzige Fenster ist
-
winexec schrieb:
verstehe ich nicht, es gibt keine standard Window Proc da der Dialog das einzige Fenster ist
doch die standard wnd proc namens DefaultWindowProc meint Martin.
-
durch das return TRUE; am Ende von WM_PAINT wird die Def Wnd Proc sowieso nicht aufgerufen -.-
-
winexec schrieb:
durch das return TRUE; am Ende von WM_PAINT wird die Def Wnd Proc sowieso nicht aufgerufen -.-
omg
-
Ich checks jetzt auch nicht.
CreateDialog()'s DialogProcess() braucht doch außerdem kein DefWindowProc().
-
-
Rabiat39 schrieb:
winexec schrieb:
verstehe ich nicht, es gibt keine standard Window Proc da der Dialog das einzige Fenster ist
doch die standard wnd proc namens DefaultWindowProc meint Martin.
Mein ich meinte das die Orginal Fenster Prozedur, des gesubclassten Fensters nicht aufgerufen wird.
Grundsätzlich:
1. Auch ein Dialog hat eine Fensterprozedur.
2. Diese Dialog fenster Prozedur ist im Windows implementiert und man kommt nicht an sie ran.
3. Diese Fensterprozedur ruft die DialogProc auf, die der User angibt, mach abr seinen eigenen Stiefel zusätzlich.
4. Wenn man also an die Fensterprozedur des Diaoges will bleibt einem nur der Subclass.
5. WM_PAINT kann man nicht subclassen, da man nicht mehrfach BeginPaint EndPaint, beliebig aufrufen kann. Das Paintrect ist nach dem ersten Aufruf nämlich leer! Ohne diese Information kann man WM_PAINT nicht korrekt nutzen.
6. deshalb ruft man eben nicht die orginal WindProc auf, die man sich beim Subclass gemerkt hat.
7. Wenn man einen Subclass durchführt. sollte man DefWindowProc gar nicht benutzen sondern immer die original Fenster Prozedur aufrufen (außer man weiß was man tut)
-
danke für die Infos! Dann benutze ich ab jetzt immer CreateWindow als Hauptfenster wenn ich WM_PAINT benutzen will.
