Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Lockwindowupdate vs WM_SETREDRAW
279 views
Skip to first unread message
Klaus Ketelaer
Dec 17, 2015, 9:19:33 AM12/17/15
to
Hallo zusammen,
ich schreibe gerade ein Steuerelement, basierend auf einem
Listview oder Treeview (habe mich noch nicht entschieden),
in dem die Einträge per Button verschoben werden können.
Wegen der Diskussion, die wir kürzlich hier hatten, und ich
trotz meines Alters noch lernfähig bin, wollte ich nun statt
LockWindowUpdate lieber WM_SETREDRAW verwenden, um ein Flackern
des Bildschirms zu vermeiden.
Der Code ist banal und in der Liste befinden sich etwa 20 Einträge.
lResult = SendMessage(lv.hWnd, WM_SETREDRAW, 0, 0)
'Call LockWindowUpdate(lv.hWnd)
Set LiBuffer = lv.SelectedItem
If Not LiBuffer Is Nothing Then
Index = LiBuffer.Index
lv.ListItems.Remove Index
With LiBuffer
Index = IIf(Button.Key = "dn", Index + 1, Index - 1)
Set Li = lv.ListItems.Add(Index, .Key, .Text, .Icon, .SmallIcon)
Li.Tag = .Tag
End With
Li.Selected = True
Set lv.SelectedItem = Li
End If
'Call LockWindowUpdate(0)
lResult = SendMessage(lv.hWnd, WM_SETREDRAW, 1, 0)
Wie kann es sein, dass beim Verschieben der Einträge die
Liste flackert wie Teufel, wenn ich WM_SETREDRAW verwende,
aber absolut ruhig ist (und deutlich schneller), wenn ich
wie gewohnt LockWindowUpdate verwende?
Mir ist das im Grunde egal, und schreibe das nur, weil ich
eure Ausführungen in keiner Weise nachvollziehen kann und
konnte.
In den vielen, vielen Jahren habe ich noch niemals Probleme
mit LockWindowUpdate gehabt, und die Funktion arbeitet immer
wie gewünscht. Als vielleicht schlichtes Gemüt verwende ich
einfach das, was funktoniert und auch immer funktioniert hat.
Egal was das MSDN schreibt.
Gruß Klaus
ich schreibe gerade ein Steuerelement, basierend auf einem
Listview oder Treeview (habe mich noch nicht entschieden),
in dem die Einträge per Button verschoben werden können.
Wegen der Diskussion, die wir kürzlich hier hatten, und ich
trotz meines Alters noch lernfähig bin, wollte ich nun statt
LockWindowUpdate lieber WM_SETREDRAW verwenden, um ein Flackern
des Bildschirms zu vermeiden.
Der Code ist banal und in der Liste befinden sich etwa 20 Einträge.
lResult = SendMessage(lv.hWnd, WM_SETREDRAW, 0, 0)
'Call LockWindowUpdate(lv.hWnd)
Set LiBuffer = lv.SelectedItem
If Not LiBuffer Is Nothing Then
Index = LiBuffer.Index
lv.ListItems.Remove Index
With LiBuffer
Index = IIf(Button.Key = "dn", Index + 1, Index - 1)
Set Li = lv.ListItems.Add(Index, .Key, .Text, .Icon, .SmallIcon)
Li.Tag = .Tag
End With
Li.Selected = True
Set lv.SelectedItem = Li
End If
'Call LockWindowUpdate(0)
lResult = SendMessage(lv.hWnd, WM_SETREDRAW, 1, 0)
Wie kann es sein, dass beim Verschieben der Einträge die
Liste flackert wie Teufel, wenn ich WM_SETREDRAW verwende,
aber absolut ruhig ist (und deutlich schneller), wenn ich
wie gewohnt LockWindowUpdate verwende?
Mir ist das im Grunde egal, und schreibe das nur, weil ich
eure Ausführungen in keiner Weise nachvollziehen kann und
konnte.
In den vielen, vielen Jahren habe ich noch niemals Probleme
mit LockWindowUpdate gehabt, und die Funktion arbeitet immer
wie gewünscht. Als vielleicht schlichtes Gemüt verwende ich
einfach das, was funktoniert und auch immer funktioniert hat.
Egal was das MSDN schreibt.
Gruß Klaus
Ulrich Möller
Dec 17, 2015, 3:15:52 PM12/17/15
to
ich habe das bei mir gerade mal mit einem kleinen Testprogramm unter
(Win 8.1/64) ausprobiert, und konnte zwischen den Versionen einmal mit
Lock... und einmal mit SendRedraw... keinen Unterschied feststellen. In
beiden Fällen hat nichts geflackert.
Allerdings habe ich wie hier beschrieben
https://msdn.microsoft.com/en-us/library/windows/desktop/dd145219(v=vs.85).aspx
<https://msdn.microsoft.com/en-us/library/windows/desktop/dd145219%28v=vs.85%29.aspx>
noch ein RedrawWindow angefügt.
Pragmatisch würde ich also erstmal SendRedrawWindow versuchen
einzusetzen, solange es in dem Szenario funktioniert, ansonsten einfach
LockWindowUpdate.
Ulrich
Wolfgang Wolf
Dec 18, 2015, 1:34:38 AM12/18/15
to
Am 17.12.2015 um 15:19 schrieb Klaus Ketelaer:
> Wie kann es sein, dass beim Verschieben der Einträge die
> Liste flackert wie Teufel, wenn ich WM_SETREDRAW verwende,
> aber absolut ruhig ist (und deutlich schneller), wenn ich
> wie gewohnt LockWindowUpdate verwende?
>
Kann es sein, dass du dich mit dieser Aktion in einem Szenario
> Liste flackert wie Teufel, wenn ich WM_SETREDRAW verwende,
> aber absolut ruhig ist (und deutlich schneller), wenn ich
> wie gewohnt LockWindowUpdate verwende?
>
befindest, für den explizit LockWindowUpdate vorgesehen ist? MS schreibt
dazu: "The purpose of the LockWindowUpdate function is to permit
drag/drop feedback to be drawn over a window without interference from
the window itself. The intent is that the window is locked when feedback
is drawn and unlocked when feedback is complete. LockWindowUpdate is not
intended for general-purpose suppression of window redraw". Bei unserer
letzten Diskussion ging es um das Befüllen von TreeViews. Und hier
machst du Drag&drop-Aktionen, wenn ich das richtig verstehe (habe dein
Beispiel noch nicht ausprobiert).
Schönen Gruß
W. Wolf
Wolfgang Wolf
Dec 18, 2015, 1:37:43 AM12/18/15
to
Am 18.12.2015 um 07:35 schrieb Wolfgang Wolf:
> Bei unserer letzten Diskussion ging es um das Befüllen von TreeViews.
Sorry, das ist nicht richtig: Es war wohl das ein- und ausklappen von
> Bei unserer letzten Diskussion ging es um das Befüllen von TreeViews.
Nodes.
Schönen Gruß
W. Wolf
Klaus Ketelaer
Dec 18, 2015, 2:56:23 AM12/18/15
to
Am 17.12.2015 um 21:16 schrieb Ulrich Möller:
> Am 17.12.2015 um 15:19 schrieb Klaus Ketelaer:
>>
>> Wie kann es sein, dass beim Verschieben der Einträge die
>> Liste flackert wie Teufel, wenn ich WM_SETREDRAW verwende,
>> aber absolut ruhig ist (und deutlich schneller), wenn ich
>> wie gewohnt LockWindowUpdate verwende?
>>
>
> Am 17.12.2015 um 15:19 schrieb Klaus Ketelaer:
>>
>> Wie kann es sein, dass beim Verschieben der Einträge die
>> Liste flackert wie Teufel, wenn ich WM_SETREDRAW verwende,
>> aber absolut ruhig ist (und deutlich schneller), wenn ich
>> wie gewohnt LockWindowUpdate verwende?
>>
>
> ich habe das bei mir gerade mal mit einem kleinen Testprogramm unter
> (Win 8.1/64) ausprobiert, und konnte zwischen den Versionen einmal mit
> Lock... und einmal mit SendRedraw... keinen Unterschied feststellen. In
> beiden Fällen hat nichts geflackert.
>
> Allerdings habe ich wie hier beschrieben
> https://msdn.microsoft.com/en-us/library/windows/desktop/dd145219(v=vs.85).aspx
> <https://msdn.microsoft.com/en-us/library/windows/desktop/dd145219%28v=vs.85%29.aspx>
>
> noch ein RedrawWindow angefügt.
>
> Pragmatisch würde ich also erstmal SendRedrawWindow versuchen
> einzusetzen, solange es in dem Szenario funktioniert, ansonsten einfach
> LockWindowUpdate.
Hallo Ulrich,
> (Win 8.1/64) ausprobiert, und konnte zwischen den Versionen einmal mit
> Lock... und einmal mit SendRedraw... keinen Unterschied feststellen. In
> beiden Fällen hat nichts geflackert.
>
> Allerdings habe ich wie hier beschrieben
> https://msdn.microsoft.com/en-us/library/windows/desktop/dd145219(v=vs.85).aspx
> <https://msdn.microsoft.com/en-us/library/windows/desktop/dd145219%28v=vs.85%29.aspx>
>
> noch ein RedrawWindow angefügt.
>
> Pragmatisch würde ich also erstmal SendRedrawWindow versuchen
> einzusetzen, solange es in dem Szenario funktioniert, ansonsten einfach
> LockWindowUpdate.
ich kann da keinen Unterschied erkennen. RedrawWindow scheint
mir doppelt gemoppelt. Nach WM_SETREDRAW True ist der Inhalt
ja bereits aktuell.
Vermutlich flackert bei Dir nichts, weil Du einen schnellen
Rechner mit schneller Grafik verwendest.
Gruß Klaus
Klaus Ketelaer
Dec 18, 2015, 2:59:06 AM12/18/15
to
Am 18.12.2015 um 07:35 schrieb Wolfgang Wolf:
ich mache kein D&D, sondern enferne Nodes, die dann an anderer
Position direkt wieder eingefügt werden. Das in schneller Folge.
Es ist aber ganz egal, ob ich ein Treeview oder Listview befülle,
oder darin Nodes/Listitems in schneller Folge entferne und wieder
einfüge. Mit LockWindowUpdate funktioniert das perfekt.
Mit WM_SETREDRAW flackert es gewaltig und ist extrem langsam.
Mir ist es auch ziemlich egal, wofür M$ die Funktion geschaffen
hat. Mir kommt es auf das Resultat an. Bei D&D soll doch auch nur
verhindert werden, dass das Fenster laufend neu gezeichnet wird.
Wo hier der Unterschied liegen soll, habe ich schon beim letzten
mal nicht verstanden.
Wenn ich 100 Nodes in ein Treeview einfüge, dann wird das Ding
über 100 mal neu gezeichnet. Für mich ist das das Gleiche. Alles
was ich will, ist, dass zwischen LockWindowUpdate(hwnd) und
LockWindowUpdate(0) absolut nichts im Fenster aktualisiert wird.
Genau das macht LockWindowUpdate.
Weil es meinen Anwendungen durchaus passieren kann, dass sie auf
einem P3/800 mit 32 MB OnBoard-Grafik installiert werden, nutze
ich zur Programmierung eine "Schlaftablette". Auf einem Quadcore
mit 2GB GraKa und SSD flackert auch WM_SETREDRAW nicht.
In der letzten Diskussion wurde ja energisch bestritten, dass
LockWindowUpdate das Flackern des Bildschirms verhindert. Es wurde
gar behauptet, dass LockWindowUpdate den ganzen Desktop zu flackern
bringt.
Gruss Klaus
Ulrich Möller
Dec 18, 2015, 7:53:31 AM12/18/15
to
du hast recht. Wenn man genug CPU Power hat, flackert nichts. Also habe
ich kurzerhand das Ganze in einer VM mit reduzierter CPU Leistung
nochmal durchgetestet, sowohl mit dem Listview aus vb5 als auch vb6 und
den Versionen mit LockWindowupdate und SendRedrawWindow. Beide
verhielten sich vollkommen identisch (leichtes Flackern). Nach einem Tip
auf ActiveVB habe ich das Listview auch mal in eine Picturebox gesetzt.
Etwas besser aber flackerte immer noch ein wenig.
Was ich aber beobachten konnte, war, daß die Wahl des Fonts bzw.
Fonttypes entscheidenden Einfluß auf das flackern hatte. Mit dem
Standardfont "MS Sans Serif" flackerte absolut gar nichts mehr, selbst
ohne zusätzliche Maßnahmen.
Übrigens: das RedrawWindow ist deshalb notwendig, weil SendRedrawWindow
nach dem wieder einschalten nicht automatisch einen Update durchführt.
Wenn dieser also durch nichts anderes veranlaßt wird, wird die Anzeige
nicht aktualisiert. Kann man schön an dem Experiment mit der Picturebox
nachvollziehen. RedrawWindow soll dabei etwas intelligenter vorgehen,
als das nackte invalidate.
Manchmal ist ein Test mit älter Hardware doch noch sinnvoll und man
erkennt Dinge, die mit heutiger CPU Leistung und üppigem Speicher nicht
mehr auffallen.
Gruß
Ulrich
Klaus Ketelaer
Dec 18, 2015, 8:32:28 AM12/18/15
to
Am 18.12.2015 um 13:53 schrieb Ulrich Möller:
> Am 18.12.2015 um 08:56 schrieb Klaus Ketelaer:
>> Vermutlich flackert bei Dir nichts, weil Du einen schnellen
>> Rechner mit schneller Grafik verwendest.
>>
Hallo Ulrich,
> Am 18.12.2015 um 08:56 schrieb Klaus Ketelaer:
>> Vermutlich flackert bei Dir nichts, weil Du einen schnellen
>> Rechner mit schneller Grafik verwendest.
>>
> du hast recht. Wenn man genug CPU Power hat, flackert nichts. Also habe
> ich kurzerhand das Ganze in einer VM mit reduzierter CPU Leistung
> nochmal durchgetestet, sowohl mit dem Listview aus vb5 als auch vb6 und
> den Versionen mit LockWindowupdate und SendRedrawWindow. Beide
> verhielten sich vollkommen identisch (leichtes Flackern).
Also bei mir gewinnt LockWindowUpdate mit deutlichem Vorsprung.
> ich kurzerhand das Ganze in einer VM mit reduzierter CPU Leistung
> nochmal durchgetestet, sowohl mit dem Listview aus vb5 als auch vb6 und
> den Versionen mit LockWindowupdate und SendRedrawWindow. Beide
> verhielten sich vollkommen identisch (leichtes Flackern).
Auch auf meinem 2. Arbeitsrechner Athlon 2 X2 250, 2x3 GHz,
16 GB RAM, HD3000 OnBoard, ist das Verhalten reproduzierbar.
Vielleicht liegt es ja auch an einer DirectX Version, dass das
bei mir so deutlich zum tragen kommt. Weiss der Henker.
In der originalen Version des Codes führe ich, nachdem ein Item
verschoben wurde, noch 2 SQLStatements aus, die die Position der
Einträge auf meinem MySql-Server in Karlsruhe updaten. Das kostet
auch eine Menge Zeit (in Relation zum Listitem einfügen).
Vielleicht ist das Verhalten deshalb bei mir so eindeutig
> Nach einem Tip
> auf ActiveVB habe ich das Listview auch mal in eine Picturebox gesetzt.
> Etwas besser aber flackerte immer noch ein wenig.
LockWindowUpdate;-)
> Was ich aber beobachten konnte, war, daß die Wahl des Fonts bzw.
> Fonttypes entscheidenden Einfluß auf das flackern hatte. Mit dem
> Standardfont "MS Sans Serif" flackerte absolut gar nichts mehr, selbst
> ohne zusätzliche Maßnahmen.
Fällen weiche ich mal auf Courier New aus. Aber auch da
flackert dank LockWindowUpdate nichts.
> Übrigens: das RedrawWindow ist deshalb notwendig, weil SendRedrawWindow
> nach dem wieder einschalten nicht automatisch einen Update durchführt.
> Wenn dieser also durch nichts anderes veranlaßt wird, wird die Anzeige
> nicht aktualisiert. Kann man schön an dem Experiment mit der Picturebox
> nachvollziehen. RedrawWindow soll dabei etwas intelligenter vorgehen,
> als das nackte invalidate.
korrekten Inhalte. Komisch...
>
> Manchmal ist ein Test mit älter Hardware doch noch sinnvoll und man
> erkennt Dinge, die mit heutiger CPU Leistung und üppigem Speicher nicht
> mehr auffallen.
was einen beim Kunden erwartet, oder wenn man wie ich zu geizig
ist, alle Nase lang neue Rechner zu kaufen. Ich entwickle immer
auf dem untersten (für mich) vorstellbaren Rechner-Niveau. Das
hat sich immer bezahlt gemacht.
Ich werde einfach mein LockWindowUpdate wie gewohnt verwenden.
Never change a runnig program;-)
Gruß Klaus
Ulrich Möller
Dec 18, 2015, 8:55:34 AM12/18/15
to
also wenn deiner Hardware bzw, deine Windows-Installation mit
LockWindowUpdate besser zurechtkommt, warum nicht? Erst wenn eine
Interaktion mit anderen Programmen auftritt, besteht vielleicht
Handlungsbedarf. Da das ganze Interaktiv läuft und sich das Ganze im
Millisekunden Bereich abspielt, sollte sich also ein Lock nicht negativ
auswirken.
In den Sinne, "Never change a runnig program". Sehe ich genauso!
Nebenbei: vielleicht könnte man das auch einfach mit einer Listbox
erledigen?
Gruß
Ulrich
Ulrich Möller
Dec 18, 2015, 3:55:42 PM12/18/15
to
Hallo Klaus,
das Thema mit dem Flackern vom ListView hat mich doch nicht losgelassen.
Unabhängig von LockWindow oder SendRedrawWindow hatte ich noch im
Hinterkopf, daß man auch Doublebuffering für das Listview aktivieren
könnte, dann flackert zumindest bei mir nichts mehr. Ein kleines
Testprojekt ist
hier verfügbar:
http://1drv.ms/1k74faV
Ulrich
das Thema mit dem Flackern vom ListView hat mich doch nicht losgelassen.
Unabhängig von LockWindow oder SendRedrawWindow hatte ich noch im
Hinterkopf, daß man auch Doublebuffering für das Listview aktivieren
könnte, dann flackert zumindest bei mir nichts mehr. Ein kleines
Testprojekt ist
hier verfügbar:
http://1drv.ms/1k74faV
Ulrich
Wolfgang Wolf
Dec 21, 2015, 2:19:13 AM12/21/15
to
Am 18.12.2015 um 08:59 schrieb Klaus Ketelaer:
>
> Weil es meinen Anwendungen durchaus passieren kann, dass sie auf
> einem P3/800 mit 32 MB OnBoard-Grafik installiert werden, nutze
> ich zur Programmierung eine "Schlaftablette". Auf einem Quadcore
> mit 2GB GraKa und SSD flackert auch WM_SETREDRAW nicht.
>
Zu einer vollständigen Anwendung gehören neben dem Programmieren weitere
>
> Weil es meinen Anwendungen durchaus passieren kann, dass sie auf
> einem P3/800 mit 32 MB OnBoard-Grafik installiert werden, nutze
> ich zur Programmierung eine "Schlaftablette". Auf einem Quadcore
> mit 2GB GraKa und SSD flackert auch WM_SETREDRAW nicht.
>
Tätigkeiten, bei denen man froh ist wenn der eigene Rechner einigermaßen
performt.
Unser VB hat draußen beim Kunden weniger Probleme mit der
Rechnerperformance, sondern eher mit den Belangen neuester
Betriebssysteme. Beides kann man schwer auf einer Maschine abbilden:
schwache Performance und aktuellstes Betriebssystem. Weil diese
Kreis-Quadratur nicht möglich ist, entscheide ich mich weder für das
eine noch für das andere, sondern bevorzuge die Umgebung in der ich mich
am wohlsten und effektivsten fühle. Danach muss man halt beide Extreme
noch mal testen.
> Mir ist es auch ziemlich egal, wofür M$ die Funktion geschaffen
> hat. Mir kommt es auf das Resultat an. Bei D&D soll doch auch nur
> verhindert werden, dass das Fenster laufend neu gezeichnet wird.
> Wo hier der Unterschied liegen soll, habe ich schon beim letzten
> mal nicht verstanden.
bekannt. Ich versuche mich deshalb so weit wie möglich an die
MS-Empfehlungen zu halten. Ich verwende WM_SETREDRAW nur im Zusammenhang
mit TreeViews und kann hier keinerlei Nachteile gegenüber
LockWindowUpdate feststellen (mit ca. unterschiedlichen 100 Rechner im
Einsatz). Also bleibe ich bei der empfohlenen Variante. Aber wie Ulrich
bereits herausgefunden hat, scheinen unterschiedliche Randbedingungen
das alles zu beeinflussen, weshalb das Verhalten in meiner Umgebung ganz
anders sein kann als in deiner. Daher kann ich auch nur sagen: Lass dein
Bauchgefühl entscheiden. Du bist lange genug dabei, da entwickelt sich
so was... ;-)
Schönen Gruß
W. Wolf
Klaus Ketelaer
Dec 22, 2015, 5:08:45 AM12/22/15
to
danke für den Link.
Mal abgesehen davon, dass bei diesem Projekt die Darstellung
der Items total fehlerhaft ist, flackert das Ding stärker
als alles, was bei mir bisher geflackert hat;-)
Gruß Klaus
Klaus Ketelaer
Dec 22, 2015, 5:10:05 AM12/22/15
to
Am 18.12.2015 um 14:55 schrieb Ulrich Möller:
> Nebenbei: vielleicht könnte man das auch einfach mit einer Listbox
> erledigen?
Wenn eine Listbox Icons abbilden und viele Daten speichern kann,
> Nebenbei: vielleicht könnte man das auch einfach mit einer Listbox
> erledigen?
dann vielleicht;-)
Ulrich Möller
Dec 22, 2015, 5:55:29 AM12/22/15
to
dieses scheint wieder ein Problem zu sein, wo äußere Abhängigkeiten und
Bedingungen unterschiedliche Ergebnisse erzielen und scheinbar keine
einheitliche Lösung zu finden ist.
Aber wie gesagt, war nur eine andere Idee. Wenn in deinem Umfeld
LockWindowUpdate am Besten funktioniert, würde ich das einfach auch so
benutzen.
Gruß
Ulrich
Klaus Ketelaer
Dec 22, 2015, 6:03:09 AM12/22/15
to
Am 21.12.2015 um 08:18 schrieb Wolfgang Wolf:
> Am 18.12.2015 um 08:59 schrieb Klaus Ketelaer:
>
>>
>> Weil es meinen Anwendungen durchaus passieren kann, dass sie auf
>> einem P3/800 mit 32 MB OnBoard-Grafik installiert werden, nutze
>> ich zur Programmierung eine "Schlaftablette". Auf einem Quadcore
>> mit 2GB GraKa und SSD flackert auch WM_SETREDRAW nicht.
>>
>
> Zu einer vollständigen Anwendung gehören neben dem Programmieren weitere
> Tätigkeiten, bei denen man froh ist wenn der eigene Rechner einigermaßen
> performt.
Was wäre das denn? PowerDVD?
> Am 18.12.2015 um 08:59 schrieb Klaus Ketelaer:
>
>>
>> Weil es meinen Anwendungen durchaus passieren kann, dass sie auf
>> einem P3/800 mit 32 MB OnBoard-Grafik installiert werden, nutze
>> ich zur Programmierung eine "Schlaftablette". Auf einem Quadcore
>> mit 2GB GraKa und SSD flackert auch WM_SETREDRAW nicht.
>>
>
> Zu einer vollständigen Anwendung gehören neben dem Programmieren weitere
> Tätigkeiten, bei denen man froh ist wenn der eigene Rechner einigermaßen
> performt.
> Unser VB hat draußen beim Kunden weniger Probleme mit der
> Rechnerperformance, sondern eher mit den Belangen neuester
> Betriebssysteme.
> Beides kann man schwer auf einer Maschine abbilden:
> schwache Performance und aktuellstes Betriebssystem. Weil diese
> Kreis-Quadratur nicht möglich ist, entscheide ich mich weder für das
> eine noch für das andere, sondern bevorzuge die Umgebung in der ich mich
> am wohlsten und effektivsten fühle. Danach muss man halt beide Extreme
> noch mal testen.
beseitigen. Was hilft es mir, wenn ich mit den Resourcen rum
saue, und das erst bei abschließenden Tests bemerke?
Bei meinen Anwendern muss ich damit rechnen, dass meine Software
auf einem P3/800 mit 512 MB RAM und 4GB Flash zum Einsatz kommt,
oder irgendwelchen Thin Clients, auf denen gerade mal W2K oder
XP laufen.
>
>> Mir ist es auch ziemlich egal, wofür M$ die Funktion geschaffen
>> hat. Mir kommt es auf das Resultat an. Bei D&D soll doch auch nur
>> verhindert werden, dass das Fenster laufend neu gezeichnet wird.
>> Wo hier der Unterschied liegen soll, habe ich schon beim letzten
>> mal nicht verstanden.
>
>Aber wie Ulrich
> bereits herausgefunden hat, scheinen unterschiedliche Randbedingungen
> das alles zu beeinflussen, weshalb das Verhalten in meiner Umgebung ganz
> anders sein kann als in deiner. Daher kann ich auch nur sagen: Lass dein
> Bauchgefühl entscheiden. Du bist lange genug dabei, da entwickelt sich
> so was... ;-)
Ja, dass tue ich ja auch und lasse mich dabei auch nicht beirren;-)
> bereits herausgefunden hat, scheinen unterschiedliche Randbedingungen
> das alles zu beeinflussen, weshalb das Verhalten in meiner Umgebung ganz
> anders sein kann als in deiner. Daher kann ich auch nur sagen: Lass dein
> Bauchgefühl entscheiden. Du bist lange genug dabei, da entwickelt sich
> so was... ;-)
Ich habe dieses Thema ja nur noch einmal angeschnitten, weil ich beim
letzten mal quasi für blöd erklärt wurde, weil ich LockWindowUpdate
einsetze.
| Das Gerücht, man könnte mit LockWindowUpdate "flackern" unterdrücken,
| hält sich hartnäckig. Tatsächlich verschlimmert das nur:
| jetzt "flackert" der ganze Desktop (der ein Explorer-Fenster ist).
Als wenn ich keine Augen im Kopf hätte... (Deswegen habe ich ja auch
so angefressen reagiert:-()
Man kann mit LockWindowUpdate definitiv "flackern" unterdrücken, und
der Desktop flackert dabei definitiv nicht. Sicherlich wird man auch
Unsinn mit dieser Funktion verzapfen können.
Bei mir laufen überwiegend eigene Anwendungen, die, bis auf wenige
Ausnahmen, fast alle TreeViews oder ListViews einsetzen. Wenn ein
LockWindowUpdate so reagieren würde wie "Ulrich Korndoerfer" das
beschrieben hat, dann wäre mein Desktop ein Multi-Stroboskop.
Ich kannte bisher nur LockWindowUpdate. Entsprechend oft kommt es
bei mir zum Einsatz. Jedoch immer nur als
LockWindowUpdate(hwnd)
for i = 1 to xxx
tv.nodes add...
lv.listitems.add ...
next i
LockWindowUpdate(0)
Dieses Beispiel ist auch mit der anderen Methode deutlich langsamer.
Zumindest bei mir. Solange mir nicht von Problemen berichtet wird,
bleibe ich bei LockWindowUpdate;-)
Gruß Klaus
Ulrich Korndoerfer
Dec 23, 2015, 3:13:55 AM12/23/15
to
Klaus Ketelaer schrieb:
> ...
vielleicht). Ich gab einen Hinweis, den Du offensichtlich nicht
verstanden hast.
> | Das Gerücht, man könnte mit LockWindowUpdate "flackern" unterdrücken,
> | hält sich hartnäckig. Tatsächlich verschlimmert das nur:
> | jetzt "flackert" der ganze Desktop (der ein Explorer-Fenster ist).
>
> Als wenn ich keine Augen im Kopf hätte... (Deswegen habe ich ja auch
> so angefressen reagiert:-()
>
> Man kann mit LockWindowUpdate definitiv "flackern" unterdrücken, und
> der Desktop flackert dabei definitiv nicht. ...
Nein, kann man nicht. Ich glaube zwar nicht daß es Sinn macht mit Dir da
drüber zu diskutieren, da Du anscheinend merkfrei bist, aber da ich hier
direkt angesprochen wurde: ist Dir schon aufgefallen, daß man im Laufe
dieser "Diskussion" die Erkenntnis gewinnen konnte, daß trotz
LockWindowUpdate "flackern" auftreten kann und auch auftritt? Unter
Verhindern von Flackern verstehe ich was anderes.
Und LockWindowUpdate sperrt nun mal den kompletten Desktop,
SetWindowRedraw dagegen nur gezielt das angesprochene Fenster. Da nehm
ich doch lieber die Variante, die im ungünstigen Fall geringere
Auswirkungen hat.
--
Ulrich Korndoerfer
VB tips, helpers, solutions -> http://www.prosource.de/Downloads/
MS Newsgruppen Alternativen -> http://www.prosource.de/ms-ng-umzug.html
> ...
> Ich habe dieses Thema ja nur noch einmal angeschnitten, weil ich beim
> letzten mal quasi für blöd erklärt wurde, weil ich LockWindowUpdate
> einsetze.
>
Wer soll das getan haben? Ich nicht (gedacht habe ich es mir
> letzten mal quasi für blöd erklärt wurde, weil ich LockWindowUpdate
> einsetze.
>
vielleicht). Ich gab einen Hinweis, den Du offensichtlich nicht
verstanden hast.
> | Das Gerücht, man könnte mit LockWindowUpdate "flackern" unterdrücken,
> | hält sich hartnäckig. Tatsächlich verschlimmert das nur:
> | jetzt "flackert" der ganze Desktop (der ein Explorer-Fenster ist).
>
> Als wenn ich keine Augen im Kopf hätte... (Deswegen habe ich ja auch
> so angefressen reagiert:-()
>
> Man kann mit LockWindowUpdate definitiv "flackern" unterdrücken, und
Nein, kann man nicht. Ich glaube zwar nicht daß es Sinn macht mit Dir da
drüber zu diskutieren, da Du anscheinend merkfrei bist, aber da ich hier
direkt angesprochen wurde: ist Dir schon aufgefallen, daß man im Laufe
dieser "Diskussion" die Erkenntnis gewinnen konnte, daß trotz
LockWindowUpdate "flackern" auftreten kann und auch auftritt? Unter
Verhindern von Flackern verstehe ich was anderes.
Und LockWindowUpdate sperrt nun mal den kompletten Desktop,
SetWindowRedraw dagegen nur gezielt das angesprochene Fenster. Da nehm
ich doch lieber die Variante, die im ungünstigen Fall geringere
Auswirkungen hat.
--
Ulrich Korndoerfer
VB tips, helpers, solutions -> http://www.prosource.de/Downloads/
MS Newsgruppen Alternativen -> http://www.prosource.de/ms-ng-umzug.html
Ulrich Korndoerfer
Dec 23, 2015, 3:18:46 AM12/23/15
to
Sorry,
> ... daß trotz
> ... daß trotz
> LockWindowUpdate "flackern" auftreten kann und auch auftritt?
Lies: daß wegen
Klaus Ketelaer
Dec 23, 2015, 4:24:10 AM12/23/15
to
Am 23.12.2015 um 09:13 schrieb Ulrich Korndoerfer:
Wer behauptet, dass man mit LockWindowUpdate kein Flackern unterdrücken
kann, der ist ein merkbefreiter Idiot.
for i=1 to 100
Listview1.additem ,,"Test"
next i
bringt das Listview Steuerelement ganz wild zum flackern. Mit einem
LockWindowUpdate drumherum flackert nichts. Auch wenn die Sperre
aufgehoben wird flackert nichts. Warum auch? Wenn ein Neuzeichnen
des Desktops ein Flackern erzeugen würde, dann würden alle Desktops
auf diesem Planeten den ganzen Tag lang flackern.
Es geht nicht darum, wie es besser geht, es geht nicht darum, was
LockWindowUpdate sperrt und es geht auch nicht darum, was Du Töffel
unter flackern verstehst, oder was Du lieber nimmst.
Es geht einzig und allein um die Aussage, dass man mit LockWindowUpdate
Flackern unterdrücken kann.
Jeder normale Mensch kann sehen, ob das Listview in dem o.g. Beispiel
flackert oder nicht. Selbst ein Kleinkind kann erkennen, dass es mit
einem LockWindowUpdate nicht flackert.
Und wenn Du sinnentnehmend lesen könntest, dann hätte sich Dir erschlossen,
dass hier auch Andere reproduzieren konnten, dass es mit Deiner Methode
mitunter schlimmer flackert als mit LockwindowUpdate.
Bei Deiner Methode muss man auch noch eine aufwändige Fehlerbehandlung
implementieren, damit das Fenster nach einem Fehler nicht dauerhaft
gesperrt bleibt. LockwindowUpdate ensperrtt sich nach einem Mausklick
selber. Hier kann überhaupt nichts passieren, außer dass bei wirren
Interaktionen die Sperre vielleicht mal ungewollt aufgehoben wird.
Deine Aussage
| Das Gerücht, man könnte mit LockWindowUpdate "flackern" unterdrücken,
| hält sich hartnäckig. Tatsächlich verschlimmert das nur:
| jetzt "flackert" der ganze Desktop (der ein Explorer-Fenster ist).
ist einfach nur schwachsinniges Getrolle...
Eigentlich sollte man Dich in dag° einweisen...
EOT
Wer behauptet, dass man mit LockWindowUpdate kein Flackern unterdrücken
kann, der ist ein merkbefreiter Idiot.
for i=1 to 100
Listview1.additem ,,"Test"
next i
bringt das Listview Steuerelement ganz wild zum flackern. Mit einem
LockWindowUpdate drumherum flackert nichts. Auch wenn die Sperre
aufgehoben wird flackert nichts. Warum auch? Wenn ein Neuzeichnen
des Desktops ein Flackern erzeugen würde, dann würden alle Desktops
auf diesem Planeten den ganzen Tag lang flackern.
Es geht nicht darum, wie es besser geht, es geht nicht darum, was
LockWindowUpdate sperrt und es geht auch nicht darum, was Du Töffel
unter flackern verstehst, oder was Du lieber nimmst.
Es geht einzig und allein um die Aussage, dass man mit LockWindowUpdate
Flackern unterdrücken kann.
Jeder normale Mensch kann sehen, ob das Listview in dem o.g. Beispiel
flackert oder nicht. Selbst ein Kleinkind kann erkennen, dass es mit
einem LockWindowUpdate nicht flackert.
Und wenn Du sinnentnehmend lesen könntest, dann hätte sich Dir erschlossen,
dass hier auch Andere reproduzieren konnten, dass es mit Deiner Methode
mitunter schlimmer flackert als mit LockwindowUpdate.
Bei Deiner Methode muss man auch noch eine aufwändige Fehlerbehandlung
implementieren, damit das Fenster nach einem Fehler nicht dauerhaft
gesperrt bleibt. LockwindowUpdate ensperrtt sich nach einem Mausklick
selber. Hier kann überhaupt nichts passieren, außer dass bei wirren
Interaktionen die Sperre vielleicht mal ungewollt aufgehoben wird.
Deine Aussage
| Das Gerücht, man könnte mit LockWindowUpdate "flackern" unterdrücken,
| hält sich hartnäckig. Tatsächlich verschlimmert das nur:
| jetzt "flackert" der ganze Desktop (der ein Explorer-Fenster ist).
Eigentlich sollte man Dich in dag° einweisen...
EOT
Dieter Strassner
Dec 23, 2015, 5:41:36 AM12/23/15
to
Hallo Ihr beiden,
laßt es doch bitte etwas ruhiger angehen.
Gegenseitige Beleidigen, Unterstellungen oder sonst was helfen doch
niemanden. Weder euch noch den NG-ler. Bleibt doch bitte freundlich im
Umgangston!
Jeder der hier postet, investiert seine Zeit und hat das eine oder
andere Problem zu lösen oder gibt kostenfreie Hilfe - alles freiwillig.
--
Viele Grüße - Dieter
EDV-Kommunikation Strassner e.K.
68623 Lampertheim
Internet: www.strassner.biz
laßt es doch bitte etwas ruhiger angehen.
Gegenseitige Beleidigen, Unterstellungen oder sonst was helfen doch
niemanden. Weder euch noch den NG-ler. Bleibt doch bitte freundlich im
Umgangston!
Jeder der hier postet, investiert seine Zeit und hat das eine oder
andere Problem zu lösen oder gibt kostenfreie Hilfe - alles freiwillig.
--
Viele Grüße - Dieter
EDV-Kommunikation Strassner e.K.
68623 Lampertheim
Internet: www.strassner.biz
Wendelin
Dec 23, 2015, 7:46:09 AM12/23/15
to
> Und LockWindowUpdate sperrt nun mal den kompletten Desktop,
> SetWindowRedraw dagegen nur gezielt das angesprochene Fenster.
Ratet mal, warum Windows eben Windows heißt, zu was das hWnd im
> SetWindowRedraw dagegen nur gezielt das angesprochene Fenster.
LockWindowUpdate gut ist und weshalb da kein Plural im Funktionsnamen steht?
Wer's nicht weiß sollte
https://msdn.microsoft.com/de-de/library/windows/desktop/dd145034%28v=vs.85%29.aspx
lesen
Übrigens, Flackerei hat oftmals was mit dem ReSize und ReDraw Event zu tun -
wenn's flackert, dann sollte man erst mal dort gucken, wer wann was wo warum
hinzeichnet.
Und wenn's trotzdem flackert, ein Debug.print ums LockWindowUpdate herum
kostet übrigens nix.
Ulrich Möller
Dec 23, 2015, 7:50:37 AM12/23/15
to
ich kann Dieter nur beipflichten !
Nochmal zum Thema. Wenn ich das richtig verstanden habe, sperrt
LockwindowUpdate ganze Regionen, die über das HWnd angegeben werden,
wobei bei mehreren aufrufen mit unterschiedlichen HWnds die additiv
behandelt werden. Ein Hwnd von NULL gibt dann alle Regionen wieder frei.
SetRedrawWindow ist dort etwas eleganter und berücksichtigt wohl die
einzelnen Ausgabebereiche separat, hat aber auch Probleme mit sich
überlappenden Bereichen. Zumindest ist es das, was ich bei meinen Tests
sehen konnte.
Entscheidend ist das Neuzeichnen und die Verwaltung von diesen Bereich
und wie Windows damit umgeht. Beim Neuzeichen nehme ich mal stark an,
das eine BitBlk Operation zum tragen kommt. Wie diese dann ausgeführt
wird, hängt wohl auch mit der Implementierung in den Grafiktreibern und
der Hardware zusammen. Es scheint, das zumindest auf "ältere" Hardware,
LockWindowUpdate effizienter läuft und damit ein "Flackern" weniger
sichtbar wird.Vielleicht ist auch der Verwaltungsaufwand nur etwas
geringer und lßt sich besser in der GPU umsetzen.
Das alles sind nur Vermutungen und hier würde meine Wahl durch den
erzielten optischen Eindruck gefällt werden.
Vielleicht weiß ein ambitionierter Spieleprogrammierer mehr über das Thema.
Grüße
Ulrich
Ulrich Möller
Dec 23, 2015, 7:54:30 AM12/23/15
to
(TreeViews) nicht so ohne weiteres heran kommt.
Ulrich
Wendelin
Dec 24, 2015, 1:55:58 PM12/24/15
to
> Na, so einfach ist das nicht, weil man an die Interna eines ListViews
> (TreeViews) nicht so ohne weiteres heran kommt.
Ich meinte die eigenen Events - manchmal werden die gefeuert, wenn man es
> (TreeViews) nicht so ohne weiteres heran kommt.
nicht erwartet hätte.
0 new messages