Jump to content
Incus J

Does application.processmessages behaviour differ between VCL and FMX?

Recommended Posts

In Delphi VCL I can use application.processmessages to process any queued messages, including pending events such as mouse clicks.  Firemonkey also has application.processmessages - but its behaviour seems different, in that it doesn't process queued mouse clicks on buttons.  This means that I am unable to check to see whether a Cancel button has been clicked part way through an operation.  Is this correct?  (Delphi FMX Tokyo 10.2.3)

Share this post


Link to post

The problem there might be, that FMX-Buttons are not Windows Buttons, and therefore don't rely on Windows messages. At least, that's what I remember about FMX.

Share this post


Link to post

Someone said that FMX has message processing. Since FMX is multi-platform this must mean that FMX simulates windows message processing.

I should rephrase this to a question; does FMX use actual windows message processing on Windows and simulates them/use a different approach on other platforms?

If it is not a 100% simulation on all platforms i suspect using message processing in FMX code will make the code behave differently on different platforms?

Share this post


Link to post

ProcessMessages will not work as you may expect in FMX, and definitely not on Android. I suggest avoiding ProcessMessages entirely; then it won't matter which framework or platform you're using. 

 

It may be better to describe why you think it's necessary to use it (preferably with example code), because it's likely there are other ways to solve it.

  • Like 1

Share this post


Link to post

@Incus J 

 

Using Application.ProcessMessages is not the correct way to test if the GUI is updated in a lengthy process.

Put your lengthy operation in a separate thread and add a possibility to cancel it if the GUI detects such a request.

Application.ProcessMessages can lead to many hard to find anomalies and program failures.

Edited by Leif Uneus
Spelling
  • Like 3

Share this post


Link to post

Thank you for all the responses.  It makes sense that FMX might have its own queue for UI controls.  So Application.ProcessMessages may not be viable, and there may be a much better way to solve this, somehow.  If I get a little more specific, would that help point to an alternative approach?  Here's what I have so far:

 

1. User clicks "Go"

2. UI is disabled

3. Lots of photos are processed (lengthy operation)

4. UI is enabled again

 

Apart from a Cancel button, the UI is intentionally disabled to user input during the lengthy operation.  However several UI controls are regularly updated to indicate progress (a progress bar, image list, image view).

 

This is all working OK right now.  Since the UI is disabled, re-entrancy isn't an issue.  The only thing lacking is a way to let the user cancel the lengthy operation part way through if they wish.  I'd like to keep it simple.  Is there a simple robust way to achieve a Cancel button?

 

Threads:

This scares me.  Everything I've read on Delphi tasks and threads in forum post suggests they can lead to really hard to find program failures, and the library perhaps not yet robust.  I've developed commercial software in Delphi for 20 years, but I don't feel ready for threads (or maybe the threading library isn't ready for me?).  At the moment my software is working.  Is there a safe, reliable approach to creating a Cancel button that doesn't give me the option to shoot myself, or my users, in the foot?

Share this post


Link to post
1 hour ago, Incus J said:

Threads:

This scares me.  Everything I've read on Delphi tasks and threads in forum post suggests they can lead to really hard to find program failures, and the library perhaps not yet robust.  I've developed commercial software in Delphi for 20 years, but I don't feel ready for threads (or maybe the threading library isn't ready for me?).

Don't be scared. Actually this is a prime example use case for threads. Just follow the tutorials to get a feeling (http://docwiki.embarcadero.com/RADStudio/Rio/en/Using_the_Parallel_Programming_Library) and then dive right in. You may also want to check out the answers to this SO question: https://stackoverflow.com/questions/44080089/how-to-stop-a-running-ttask-thread-safe

 

For a slightly different approach consider the classic http://docwiki.embarcadero.com/Libraries/Rio/en/System.Classes.TThread.

And then of course there is always the OmniThread library, which I have not yet played with so far, but I hear only good things.

Share this post


Link to post
14 hours ago, Incus J said:

Threads:

This scares me.  Everything I've read on Delphi tasks and threads in forum post suggests they can lead to really hard to find program failures, and the library perhaps not yet robust.  I've developed commercial software in Delphi for 20 years, but I don't feel ready for threads (or maybe the threading library isn't ready for me?).

There is nothing wrong with using threads in general, you just have to understand WHEN and HOW to use them effectively.  You can't write really high performant software without them.  Especially on mobile platforms.  I've been writing commercial software for 20 years as well, and have written many multi-threaded applications, just using Delphi's 'TThread' class.  I don't use a version that has Embarcadero's "Parallel Processing Library" available (I would never trust it anyway, it has had too many bugs over the years!), and I don't use 3rd party threading libraries, like OmniThreadLibrary, etc (not that there is anything wrong with them, I just never got into them).

  • Like 1

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×