@Chriastian:
Zitat:
hast Du noch nie Probleme mit Perform gehabt?
Ich nehm da doch lieber SendMessage.
Nein, nicht direkt. Perform() leitet nur dann Messages, die für Fensterhandles bestimmt sind, korrekt weiter wenn das Control auch ein alloziertes Fensterhandle besitzt.
SendMessage(
Handle, ....) würde in diesem Falle, oft viel zu frühzeitig, ein Fensterhandle erzeugen.
Will man also erreichen das wm_SetRedraw nur funktioniert wenn ein Fensterhandle alloziert wurde, und somit die Möglichkeit besteht das das Control auch sichtbar ist, dann sollte man mit Perform arbeiten
Ein Control ohne Fensterhandle oder Fensterhandle im Parent kann nicht sichtbar sein. Also hätte Perfrom(wm_Setredraw,...) auch keine Auswirkungen auf die automatische Allozierung beim Zugriff auf die Eigenschaft .Handle;
Normalerweise hat woki Recht. wm_Setredraw ist ein "brachial" erscheinender Weg, aber warum gibt es dann wm_SetRedraw, SetWindowsHookEx() uvm. ??
Man sollte immer erst versuchen über die Sichtbarkeit der Controls das gleiche zu erreichen. Dann als nächst tiefere Ebene mit .DisableAlgin/.EnableAlign und .Realign arbeiten.
Erst dann wird wm_SetRedraw benutzt. Der Unterschied ist das wm_Setredraw NICHTS tatsächlich beschleunigt. D.h. es werden weiterhin alle Zeichenoperationen durchgeführt, nur eben in einem ungültigen und nicht sichtbaren Gerätekontext.
Zitat:
Der Effekt wäre ein Einfrieren der Form
Dies kann ich so nicht bestätigen. Sinnvoll und vorsichtig eingesetzt beseitigt es Flickern und macht die Anzeigen eigentlich visuell "subjektiv" schneller. Schau dir mal TStrings.BeginUpdate und .EndUpdate genauer an.
Gruß Hagen