ProcessMessages and screen updating

[sfein1000]

Setup:
Linux - Debian Pixie with KDE desktop and Wayland
FPC: 3.2.2 installed using fpcupdeluxe
FPGui: 2.1.0 - compiled with unix

I am getting conflicting information between the free pascal wiki and user comments on the lazarus forum. The wiki states it is ok to use Application.ProcessMessages instead of threads while responses on forum contradict that opinion. Because of that, I may switch to using threads, but as of right now, I am converting some code from lazarus which uses Application.ProcessMessages. What the code does, is sets the caption of a label to show something like "Processing", then performs the process and then resets the caption to "Done". It calls Application.ProcessMessages to update the UI with the new caption.

I tried to do this in fpgui using:
label.Text and fpgApplication.ProcessMessages

but the UI does not update. Does the fpgui version of ProcessMessages work differently or does setting Text not create a message?

As I mentioned, this might be moot as I am probably going to convert to using threads, but thought I would ask anyway.

Thanks,
Steve

[graemeg]

Hi Steve,

Thanks for the report — this turned out to be a genuine bug in fpGUI, not a misunderstanding on your part. Your instinct was right: Label.Text := ... followed by fpgApplication.ProcessMessages should update the UI, and it wasn't.

What was going wrong

fpGUI has two message queues, and ProcessMessages was only checking one.

Setting Label.Text posts an internal FPGM_PAINT message onto fpGUI's own queue — it generates no X11 event. But ProcessMessages gated its whole body on MessagesPending, which on X11 is just XPending(display) > 0, i.e. native events only. With no X events pending the loop never ran, the internal queue was never drained, and the paint sat there until the app returned to its main loop. By then your operation had finished and paint coalescing merged the updates, so only the final "Done" was drawn — exactly why "Processing" never appeared.

In Lazarus this works because the LCL drains its queue unconditionally and hands damage straight to GTK/Qt, which track it natively. fpGUI's own queue is invisible to XPending, so the idiom didn't carry across. The wiki advice isn't wrong — our implementation had a hole in it.

Fixed

ProcessMessages now drains the internal queue unconditionally, before and after the platform loop. The per-iteration wait also dropped from 250 ms to 0, since messages are already known to be pending at that point — that was a second latent problem which could stall a caller polling in a tight loop.

Landed on develop in 5efb23f with a new tcprocessmessages test unit. The tests failed before the fix and pass after, no regressions.

On threads

For a status label around a long operation, ProcessMessages is now a reasonable choice and simpler than threading. Usual caveat applies though: while it runs, event handlers fire, so the user can re-enter your operation by clicking again — disable the relevant controls or guard with a busy flag.

If the work is genuinely long-running and you want the UI responsive throughout, threads are the better structure. fpGUI has TfpgAsyncTask in fpg_async.pas for this — it runs work on a background thread and marshals progress/completion callbacks back to the main thread. If you go that way, update widgets only from the main thread via those callbacks or fpgApplication.InvokeLater; setting Label.Text from a worker thread isn't safe.

Thanks again for raising it — clear enough to reproduce from, and this one had been lurking a while.

Graeme

[sfein1000]

Thanks for confirming. I'll take a look at TfpgAsyncTask as well. My original thought was a TThread, but if FPGui already has something that works well, might be worth using.

[sfein1000]

I modified the code to use TThread already. I'll have to create some new code to test the ProcessMessages.