While WindowEvent():Wend

[Delle]

Hallo,

ich habe Repeat:Forever laufen und dazwischen halt die üblichen Gadget-Abfragen...

Bei welchen Stellen muss ich jetzt While WindowEvent():Wend verwenden damit ev. Gadget-Umschaltungen (Hide/Show) flüssig ablaufen?

Manchmal ist bei sowas noch vllt eine 0,25 Sekunden lange Verzögerung.

Deshalb die Frage nach welchen Operationen While WindowEvent():Wend Sinn macht und wo es "nichts" bringt.

Danke!

[HeX0R]

"Sinn" macht es eigentlich nirgends.

Wenn irgendwas nicht flüssig läuft, solltest du dein Eventhandling noch mal überarbeiten.

[Kaeru Gaman]

genau.
While WindowEvent():Wend ist ein böser, böser Eventfresser,
und sollte nach möglichkeit nur angewandt werden,
wenn du ganz genau weißt was du tust und wenn es absolut nicht anders geht.
in einem normalen Eventloop hat er nichts, garnichts zu suchen, weil er dann auch Userevents frißt.


die Gadgetumschaltung sollte vom normalen WaitWindowEvent() getätigt werden.

falls du eine ständig durchlaufende Eventschleife mit WindowEvent() : Delay(Timeout) hast,
kann dadurch eine verzögerung entstehen, weil das Delay immer wartet.
In dem Falle ist ein WaitWindowEvent(Timeout) besser, weil das nur dann verzögert, wenn kein event anliegt.
außerdem ist es mit einem Timeout möglich, die Veränderungen der Gadgets nur durchzuführen,
wenn kein Event anliegt also der Rückgabewert #Null ist.
diese Verfahrensweise verhindert, dass sich Events aufstauen können
wenn mehrere Umschaltungen pro Loopdurchgang stattfinden.

[PMV]

Alternative für ältere PB-Versionen:

Code: Alles auswählen

Select WindowEvent()
  Case 0
    Delay(20)
EndSelect

MFG PMV

[Delle]

So habe den ganzen Code jetzt davon gesäubert.

Das Problem mit den Verzögerungen tritt eigentlich nur noch da auf:

1) Fenster ist unsichtbar, Gadgets sind bereits drauf, Fenster wird eingeblendet...

2) Container-Gadget wird unsichtbar gemacht und drunterliegendes sichtbar

Da erscheint ohne While/Wend dann eine "Lücke"...

[Kaeru Gaman]

wenn 1) zum programmstart auftritt, dann kannst du VOR der Haupt-Event-Schleife vor dem Sichtbarmachen aber nach dem Gadgeterstellen einen Fresser einsetzen.

für 2) gibt es bestimmt eine bessere Lösung, es ist eher ungewöhnlich/unpraktisch, eine gruppe Gadgets durch nen Container zu verdecken.

[Delle]

wenn 1) zum programmstart auftritt, dann kannst du VOR der Haupt-Event-Schleife vor dem Sichtbarmachen aber nach dem Gadgeterstellen einen Fresser einsetzen.

Fresser?

für 2) gibt es bestimmt eine bessere Lösung, es ist eher ungewöhnlich/unpraktisch, eine gruppe Gadgets durch nen Container zu verdecken.

Ungewöhnlich? Ich habe es nur aus Platzgründen so gemacht:

Container 1: Fortschrittsanzeige usw.
Container 2: Settings + "Go"-Button (direkt über Container 1)

Nach Klick auf den "Go"-Button wird Container 2 unsichtbar gemacht... Container 1 wird dann automatisch sichtbar... nach Beendigung wird wieder Container 2 sichtbar gemacht.

Nach diesen HideGadget()-Befehlen waren halt komische Hänger drin wo zwischen den Wechsel der Container lediglich der graue Hintergrund zu sehen war.

[Kaeru Gaman]

> Fresser?

na, den Eventfresser latürnich.

also, ich würde container1 unsichtbar machen, wenn 2 sichtbar ist.
Gadgets haben nativ keine z-order, es ist sozusagen purer zufall,
dass container1 wirklich verdeckt wird.

probier erstmal aus, ob das vielleicht schon das problem verringert.

wenn nicht...
also wenn du auf einen click reagierst um die gadgets zu tauschen,
kannst du direkt nach dem tausch bevor du die eventschleife wieder betrittst einen Fresser einbaun.

aber im Grunde kann es sich nur um zwei bis sechs events handeln, da ist komisch dass es verzögert.
hast du den den anderen Rat beherzigt, und dafür gesort,
dass deine schleife bei anliegenden events wirklich ohne verzögerung durchlaufen kann?