AnimateWindow() killt WM_PAINT

berniebutt

In einer DialogBox hast Du Controls wie edit, static, etc. Diese kannst Du jederzeit vom Programm beeinflussen. Alles muss über DialogProc gehen, nicht über WndProc. Ob man da mit InvalidateRect ein Neuzeichnen erzwingen kann, ist mir unbekannt. Meine Frage ist: was soll das?

Mmacher

Ich habs so interpretiert: Er möchte in einem bestimmten Bereich des Dialogs (also in ein static control) eigene Zeichenfunktionen (GDI) anwenden.
z.B. eine Darstellung mit Linien, Kreise etc.

@Bitte ein Bit:
Vielleicht willst Du eine animierte Darstellung haben? Hast Du auch schon mal an eine "Animation control" gedacht?

sri

AnimateWindow erfordert die Behandlung von WM_PRINTCLIENT.

The window procedures for the window and its child windows should handle any WM_PRINT or WM_PRINTCLIENT messages. Dialog boxes, controls, and common controls already handle WM_PRINTCLIENT. The default window procedure already handles WM_PRINT.

Bitte ein Bit

@Martin Richter:
Nee, glaube ich nicht ganz Auf http://blog.m-ri.de/?s=hModule&submit=Suchen steht nämlich die Begründung Das ist übrigens eine echt gute Seite von dir ! Danke

@berniebutt & @Martin Richter:
Darf ich mal ganz dumm fragen was der Unterschied zwischen WNDPROC und DLGPROC ist ? Ich vermute, dass wenn ich die Funktion DialogBox() aufrufe, die Funktion eine Standard-WNDPROC benutzt und nur gewisse Events an die gegebene DLGPROC weiterdelegiert. Dies aber in der MSDN zu finden, ist mir bisher nicht gelungen.

Und darf ich, bitte nicht ärgern, auch mal dumm fragen warum es Unfug ist in der DLGPROC ein WM_PAINT abzufangen? Ok ich schätze schon dass man dann auch ein DefWindowProc() aufrufen müsste, aber ansonsten habe ich trotz Doku keine Ahnung wann ich dieses Event (und damit auch andere) potientiell behandeln darf und wann nicht.

Und wo wir gerade dabei sind: Warum heißt WNDPROC WNDPROC und nicht WNDEVENTPROC ? Die Namensbezeichnung finde ich nämlich verwirrend.

Vielleicht sollte ich mir auch deswegen mal ein Buch zu dem Thema "Grundkonzepte der WinAPI" zulegen, denn ich habe bisher nur von der MSDN gelernt. Kann mir jemand vielleicht einen solchen Wälzer empfehlen ???

@Mmacher:
Nee ich möchte einfach eine GUI basteln, welche die Eingabe einfacher grafischer Primitive erlaubt. Dazu habe ich eine Menge von Buttons, welche bei einem Click auf den Button einen weiteren Dialog animiert öffnet. Der geöffnete Dialog soll eine Zeichnung der einzugebenden grafische Primitive (Strecke, Dreieck,...) sowie den aktuell einzugebenden Punkt anzeigen. Des weiteren soll der Dialog die Eingabe der Punkte ermöglichen.

Aber vielen danke für deinen Tip. Ich werde ihn mal ausprobieren. Und danke auch für die Links! Ich werde mal in nächster Zeit die Seite "The Old New Thing" durchstöbern.

Mmacher

Für "Grundkonzepte der WinAPI" werden (u.a. hier im Forum) häufig Petzold's Buch "Windows-Programmierung" und Brent + Newcomer's Buch "Win32 Programming" (englisch) erwähnt.

Für Deine Fragen bezüglich Dialoge ein paar Hintergrundwissen, als ideale Ergänzung zur MSDN-Doku:
"The dialog manager, part 1: Warm-ups": http://blogs.msdn.com/oldnewthing/archive/2005/03/29/403298.aspx
"The dialog manager, part 2: Creating the frame window": http://blogs.msdn.com/oldnewthing/archive/2005/03/30/403711.aspx
"The dialog manager, part 3: Creating the controls": http://blogs.msdn.com/oldnewthing/archive/2005/03/31/404108.aspx
"The dialog manager, part 4: The dialog loop": http://blogs.msdn.com/oldnewthing/archive/2005/04/01/404531.aspx
"The dialog manager, part 5: Converting a non-modal dialog box to modal": http://blogs.msdn.com/oldnewthing/archive/2005/04/04/405207.aspx
"The dialog manager, part 6: Subtleties in message loops": http://blogs.msdn.com/oldnewthing/archive/2005/04/05/405518.aspx
"The dialog manager, part 7: More subtleties in message loops": http://blogs.msdn.com/oldnewthing/archive/2005/04/06/405827.aspx
"The dialog manager, part 8: Custom navigation in dialog boxes": http://blogs.msdn.com/oldnewthing/archive/2005/04/07/406012.aspx
"The dialog manager, part 9: Custom accelerators in dialog boxes": http://blogs.msdn.com/oldnewthing/archive/2005/04/08/406509.aspx

Diese Links sind zwar kein Ersatz für "Einführung in die Programmierung von Dialogen", aber helfen sehr viel beim Verstehen der Funktionsweise von Dialogen.

Martin

berniebutt

@Bitte ein Bit zur Frage WndProc / DialogProc: Beides sind von Dir zu schreibende CALLBACK-Funktionen. WndProc bekommt die für das Hauptfenster bestimmten Nachrichten, DialogProc die an den Dialog bestimmten Nachrichten zu sehen. Das sollte Dir eigentlich hinreichend bekannt sein!
Zur Fragestellung: Du kannst ein static-control mit dem Style SS_BITMAP anlegen. Es wird dann ein Bitmap statt eines Textes in das static-control eingesetzt. Für die gewünschte Animation musst Du dann durch Veränderung des Bitmap und dem Senden der Nachricht SendDlgItemMessage sorgen.

Bitte ein Bit

@berniebutt
Ja das habe ich bereits vermutet, aber diese Anwort ist mir bei weitem nicht genau genug. Denn wenn ich mir die Antworten von Mmacher und Martin Richter ansehe, wobei Martin Richter ein MVP ist (also einer der wissen müsste wie die Dinge funktionieren), scheine ich ja mit meinem Vorschlag, die WM_PAINT in einer DLGPROC zu benutzen, einen Fehler zu machen. Die Frage ist nur: Warum ?
Und daraus kommt mir die Frage was denn eigentlich ein WM_PAINT bedeutet. Dies umfasst wann ein WM_PAINT geschickt wird und wohin, wie das entsprechende Fenster darauf reagiert und wohin das Ereignis weiterdelegiert wird. In der Doku nämlich steht nur dass ein Fenster diese Nachricht durch die WNDPROC empfängt, aber nicht dass nur das die WNDPROC für die Behandlung verantwortlich ist geschweige denn dass eine DLGPROC nicht WM_PAINT behandeln dürfte! Und umsomehr verwundert es mich WM_PAINT Events in der DLGPROC zu bekommen !!!

Ich will die Kernkonzepte hinter der Ereignisbehandlung verstehe. Und die bestehen nicht nur aus Eventqueue und Nachrichtenversenden! Und genau deswegen habe ich auch nach dem Unterschied zwischen DLGPROC und WNDPROC gefragt.

Übrigens läuft mein Programmteil nun. Der Tip mit der Bitmap funktionierte problemlos. Danke euch allen!

PS:

@Mmacher
Bin gerade noch am ducharbeiten deiner Materialien. Also bitte nicht meckern wenn ich zur Zeit ein paar Dinge noch nicht verstehe

Martin Richter

1. Lies mal ein Tutorial über Windows. WM_PAINT wird von der WndProc behandelt und ein Fenster ist selbst verantwortlich, dass sein Inhalt entsprechend dargestellt wird.
2. Wird von einer WndProc WM_PAINT nicht behandelt dann wird in der DefWindowProc, einfach BeginPaint/EndPaint ausgelöst, was den Hintergrund löscht (sofern definiert) und das Fenster validiert, damitkeine weitere Nachricht ausgelöst wird.
3. Eine DlgProc ist ein Handler, der von der WndProc des Dialogprozesses aufgerufen wird um dem Entwickler eine Chance zu geben auf WM_COMMAND, WM_CTLCOLOR..., WM_INITDIALOG, WM_NOTIFY zu reagieren. Das die DlgProc im Context der WndProc aufgerufen wird macht es keinen Sinn alles zu behandeln.
Scon gar nicht WM_PAINT, auch wenn diese Info durchgereicht wird.
Schau mal alleine bitte auf den Rückgabewert und vor allem auf die Komplexität wenn Du auf einen WM_NOTIFY reagieren willst. (Seieh DWL_MSGRESULT)
Verantwortlich für die Darstellung des Dialog ist (Regel 1 in Windows) eben das Fenster selber und das ist die WndProc des Dialoges und nicht die DlgProc!
4. Und wenn Du schon WM_PAINT behandelst und TRUE zurückgibst! Dann solltest Du auch das Minimum machen was ein WM_PAINT Handlereben macht. Begin/EndPaint aufrufen und nicht einfach nichts machen.

Bitte lies die MSDN. Alles was ich hier schreibe ist dort auch zu lesen!

PS: Ein MVP weiß nicht alles, aber er weiß einiges in seinem Fachgebiet.

Allerdings ist es absoluter Unfud in einer DialogProc WM_PAINT zu behandeln!
Technisch unmöglich. Eine DialogProc ist eben keine WndProc.

ich mache das aber so und es klappt Perfekt. Wie sollte man es denn sonst machen?

Martin Richter

OK, Evtl. zu hart. Aber es steht nicht da wie die Implemntierung für WM_PAINT ist.

Unter den folgenden Bedingungen kann es funktionieren.
1. Bevor die eigene WndProc des Dialoges auferufen wird wird die DlgProc aufgerufen.
2. Wenn die DlgProc TRUE zurückgibt, dann macht die WndProc des Dialoges auch nichts mehr und einfach einen return.

Das ist jedoch weder dokumentiert noch klar und deshalb eben nicht sicher.
Ich würde die WndProc des Diaoges subclassen und meinen Handler vorschalten.

Wobei ein subclass für WM_PAINT sowieso kritisch ist... aber das ist eine andere Geschichte.

WndProc? Ich benutze nur einen einzigen Dialog fürs ganze Programm, diese Rufe ich mit DialogBox auf und es klappt ganz normal mit WM_PAINT

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, 
                   PSTR szCmdLine, int iCmdShow)
{
	return DialogBox(hInstance, MAKEINTRESOURCE(IDD_DIALOG1), 0, dlg);
}
...

BOOL CALLBACK dlg(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
	switch(message)
	{
	case WM_INITDIALOG:
             AnimateWindow(hDlg, 1000, AW_SLIDE | AW_HOR_POSITIVE);  // klappt bei mir gut, keine Ahnung was der Threadersteller für Probleme hat...
             return TRUE;

	case WM_PAINT:
		hdcTarget = BeginPaint (hDlg, &ps) ;
		EndPaint (hDlg, &ps) ;
		return TRUE;

natürlich aufs nötigste gekürzt. Vielleicht hab ich auch nur was falsch verstanden

edit: Es geht doch nicht, meine Bitmap wird nicht mehr gezeichnet wenn ich AnimateWindow benutze. ALso habe ich diese lösung aus dem Thread hier benutzt:

case WM_INITDIALOG:
		AnimateWindow(hDlg, 200, AW_BLEND);
		SetTimer(hDlg, NULL, 1, (TIMERPROC)LoaderDlg);

	case WM_TIMER:
		DrawThings(hDlg);
		return TRUE;

aber auf wie viel soll ich den Timer setzen? Ist 1 millisekunde ok oder zu oft?

Martin Richter

Kann denn keiner einfach mal die MSDN lesen?

AnimateWindow:
http://msdn.microsoft.com/en-us/library/ms632669(VS.85).aspx

The window procedures for the window and its child windows should handle any WM_PRINT or WM_PRINTCLIENT messages. Dialog boxes, controls, and common controls already handle WM_PRINTCLIENT. The default window procedure already handles WM_PRINT.

ja das hab ich gelesen aber was kommt in diese Nachricht rein??
Ein case : return TRUE wird wohl nicht reichen -.-
da steht ja nicht was man in dieser Prozedur machen soll...

Mmacher

ReinerExe schrieb:

ja das hab ich gelesen aber was kommt in diese Nachricht rein??

Gratulation daß Du es geschafft hast, in der MSDN nach AnimateWindow() zu suchen.

Aber Deine Intelligenz reicht sicher aus, um mal in der MSDN nach dem Folgebegriff WM_PRINTCLIENT zu suchen, oder nicht?

Dort steht ganz klar, was Du bei Erhalt dieser Message machen sollst oder kannst.

Andere weitverbreitete Alternative:
Warum benutzt Du nicht einfach Google oder bing.com?
Suchbegriffe "WM_PRINTCLIENT AnimateWindow" eingeben und schon kann Dir geholfen werden...

Martin

hast du das selber schon mal gegoogelt!? Da sind weder gute Erklärungen noch C++ Codebeispiele

sri

Martin Richter schrieb:

Kann denn keiner einfach mal die MSDN lesen?

AnimateWindow:
http://msdn.microsoft.com/en-us/library/ms632669(VS.85).aspx

The window procedures for the window and its child windows should handle any WM_PRINT or WM_PRINTCLIENT messages. Dialog boxes, controls, and common controls already handle WM_PRINTCLIENT. The default window procedure already handles WM_PRINT.

Tja, das hatte ich auch schon eine Seite vorher geschrieben...