Flush event queue in a binded procedure?

[Andre]

Hello,

I'm using a progress bar (opened in a seperate little window in front of the others), if some tasks are taking a longer time, for example filling a listicon gadget with several 1,000 items.

To have no "freezing" effect in calling window (which contents are beeing updated like told above) I inserted a "While : WindowEvent() : Wend" after setting the progress bar to the next value.

This worked fine until now. But as I'm converting my code into using "BindEvent(...)" and related callback procedures, I'm getting the problem now, that the debugger stop my code from executing by telling the error "WindowEvent() / WaitWindowEvent() are not allowed in binded callback procedures...".

Any ideas how I could get all possible events "flushed" and avoid the window freezing effect during the update progress (like done until now by using "While : WindowEvent() : Wend") ??
Ideally without converting the whole progressbar stuff into threaded procedures...

(Sorry, haven't example code at the moment as it's spreaded over my project...)

Thank you for any help!

[netmaestro]

Did you try just removing the WindowEvent While block and seeing how it behaves? I ask because it sounds from here as though the mere act of switching to BindEvent()/BindGadgetEvent() would serve the same purpose (only better) as the event flush. BindEvent() allows all its events to happen in real time, unimpeded by any event logjams that the window might be experiencing. Maybe your issue is already solved and you just didn't realize it. That said, there are almost always better alternatives to While WindowEvent() : Wend. That one is sort of like admitting defeat and casting about for a hack. (imho only, don't want to start a war here )

[davido]

Won't PostEvent do the trick?

[Andre]

Thank you for your replies, guys

@netmaestro: I have the feeling, that you're right - at least part-wise: Since I have switched to resizable dialogs with binded update procedures not the complete program or at least the affected window is freezing during the update process (the WindowEvent() block deactivated). But some gadgets like the filled listicon or the textgadget used as title above are hidden (not programmatically by me!) during the update process.
Such things I could avoid before by using the "While : WindowEvent() : Wend" trick (which of course costed some performance...)

@davido: No, I don't think so. As the "FillHistoryListicon()" procedure is already called by the binded "UpdateSize()" procedure, and isn't handling events itself, it should just calculate the matching history events for a country and clear/fill a listicon with them again. So I don't see any use for a PostEvent()...

[Lunasole]

@davido: No, I don't think so. As the "FillHistoryListicon()" procedure is already called by the binded "UpdateSize()" procedure, and isn't handling events itself, it should just calculate the matching history events for a country and clear/fill a listicon with them again. So I don't see any use for a PostEvent()...

What about PostEvent, can try some code like this:

Code: Select all

PostEvent() ; post custom event, to be exact, which is binded to that your FillHistoryListicon() procedure
ProcedureReturn ; from FillHistoryListicon()
; then posted event is calling your procedure again (after other events in queue before this event processed in main loop), and your proc continues what it does

Something like that (if I didn't missed something from your posts).
As for me this madness looks a bit like "state machine", should work ^^