DialogBox als Hauptfenster
-
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.
-
winexec schrieb:
danke für die Infos! Dann benutze ich ab jetzt immer CreateWindow als Hauptfenster wenn ich WM_PAINT benutzen will.
Warum? Subclassing ist doch auch nicht schwierig, wenn sich gerade mal um einen Dialog handelt.
-
habe ich noch nie gemacht, und oben hast du geschrieben dass man WM_PAINT nicht subclassen kann?
-
hab außerdem ein geiles workaround gefunden
AnimateWindow mit einer Millisekunde aufrufen und in WM_PRINTCLIENT zeichnen.
-
winexec schrieb:
habe ich noch nie gemacht, und oben hast du geschrieben dass man WM_PAINT nicht subclassen kann?
OK! Ichhabe es falsch ausgedrückt. Mein Fehler.
Wenn Du WM_PAINT subclassed, dann musst Du alles selber machen und darfst die alte Fensterprozedur nicht aufrufen.Da WM_PAINT für einen Dialog sowieso nichts macht außer DefWindowProc aufzurufen, ist das subclassen ein Kinderspiel
