Eigenes TPageControl - APIs zum zeichnen?

[wicht]

Toll. Jetzt klicke ich ein bisschen hier im Forum rum und lese den letzten Post von EWeiss in seinem "Virtual Piano"-Thread. Dort schreibt der liebe Emil was von LockWindowUpdate(). Das unterdrückt den unerwünschten Effekt mit dem "Springteufel" am Tab scheinbar! Im MSDN steht aber, dass man das nicht machen soll, weil das eine "global state"-Operation ist - und hier geht es ja nur um mein eigenes Tab, ohne dass irgendetwas anderes vom Desktop beteiligt ist. WM_SETREDRAW soll dafür gut sein. Allerdings bewirkt es bei mir am TPageControl nichts... Vielleicht hat da ja noch jemand einen Hinweis - sonst bleibe ich einfach bei LockWindowUpdate(). Mir ist zur Zeit eine nicht ganz saubere Lösung lieber, als die nächsten Wochen am eigenen Tab weiter zu arbeiten, was dann noch ganz andere Probleme hat.. Blöde Einstellung, ich weiß ...


Nocheinmal Danke und liebe Grüße,

Alex

[EWeiss]

jo WM_SETREDRAW führt nicht immer zum gewünschten erfolg deshalb habe ich auch LockWindowUpdate
zusätzlich verwendet .. MSN hin und her für mich zählt letztendlich das was funktioniert
Und auf keinen Fall mit PostMessage die wartet nämlich nicht auf die Abarbeitung.

PS:
Du könntest ja nochmal ein invalidate nach WM_SETREDRAW hinterherschicken oder UpdateWindow
Dann gibt es auch noch RedrawWindowAny

' RedrawWindow zeichnet ein Fenster neu, RedrawWindowAny
' erlaubt in diesem Fall das Auslassen der RECT-Angabe
' (spart hier die Verwendung der Funktion GetClientRect).

gruss

[wicht]

Ich bin ja eigentlich kein Freund davon, Dinge zu machen, wozu z.B. das MSDN sagt "nicht so machen". Aber hier muss ich das dann wohl. Ausserdem dauert das Schließen so eines Tabs ja nicht lange und währenddessen wird sehr sicher von keinem anderen Programm irgendein Drag&Drop durch den Benutzer gemacht werden. Und selbst wenn es mal fehlschlägt ist das kein Beinbruch, es sieht nur minimal unschön für den Benutzer aus.
Deshalb nocheinmal Danke für deinen Post, den ich da entdeckt habe ...

Ups: Das PS teste ich gleich noch. Oder morgen

[EWeiss]

MSN!

Zitat:

Leider ist es damit noch nicht ganz getan: Im Gegensatz zu LockWindowUpdate nämlich wird alleine durch das Aufheben der Sperrung noch kein Neuzeichnen ausgelöst.
Ein Neuzeichnen der betroffenen Fläche ist zwar nicht zwingend notwendig, jedoch der Regelfall:
Schließlich werden Sie wollen, dass die diversen "im Versteckten" vorgenommenen Änderungen letztlich auch sichtbar werden.

Du mußt selber dafür sorgen das dein Window aktualisiert wird.
Nach WM_SETREDRAW


gruss

[wicht]

Bei den Versuchen von vorhin hat das leider nicht geklappt. Das blöde PageControl macht trotzdem den Springteufel zwischen meinen WM_SETREDRAW Aufrufen.. es scheint, als hätte WM_SETREDRAW gar keinen Einfluss auf das Verhalten - im Gegensatz zu LockWindowUpdate(). Darum ist das "danach aktualisieren" auch nicht wirklich wichtig...

[EWeiss]

Zitat von wicht:

Bei den Versuchen von vorhin hat das leider nicht geklappt. Das blöde PageControl macht trotzdem den Springteufel zwischen meinen WM_SETREDRAW Aufrufen.. es scheint, als hätte WM_SETREDRAW gar keinen Einfluss auf das Verhalten - im Gegensatz zu LockWindowUpdate(). Darum ist das "danach aktualisieren" auch nicht wirklich wichtig...

Ok! Hauptsache du kommst damit klar.
Und du führst keinen Springteufel auf die dahinter liegenden Fenster aus.
Das mußt halt testen.

gruss

[wicht]

Ich denke das passt so, sieht bis jetzt immer noch gut aus. Wenn jemand Lust hat, das Springteufel-Problem selber zu testen, würde ich wohl eine Demo zusammen kloppen. Aber das ist von mir aus nicht nötig, und Menschen haben meist anderes zu tun, als sich um des Wichtes verrückte Probleme zu kümmern