[SOLVED] progress dialog with blocked message queue

[Phoenix]

Hi,
I'd like to enable a form to be displayed while performing operations that block the system message queue (I'm attaching the source code for testing). Currently, I only get the desired result if I call "Application.ProcessMessage" in the calculation loop. I'd like to avoid using it and still achieve something similar. Currently, the only way I can think of is using an external application called with a TProcess. Is there another way? The most important thing is to not add anything to the calculation loop to maintain maximum speed. Last consideration (already implemented but to be maintained) is the need to make the form appear only if I exceed a certain number of seconds of calculation, otherwise it should not appear. Thanks for any ideas, preferably platform-independent.

[cdbc]

Hi
Calculate in a worker-thread and update your gui / form with messages...
Simplest & easiest way to achieve what you're after...
Regards Benny

[Phoenix]

Yes, reverse reasoning is conceptually the simplest and most appropriate design choice. Thank you.

I'd be curious if a cross-platform generalization is possible, such as checking when the application is stalled (not responding).

[cdbc]

Hi
If you keep your worker-thread count <= processor-count on your machine (incl. the main thread!), then it won't be /non-responsive/ 
Regards Benny

[Phoenix]

Thank you

[cdbc]

Hi
I just downloaded your test.zip and will try and put something together later tonight and tomorrow...
Regards Benny

[Phoenix]

Thanks for your interest. In any case, here's a second initial version following the new approach. The problem is that in real-world use, it's problematic when there are many calculation parameters, etc., and requires more or less lengthy modifications. It would be easier if you could use it as a simple "try finally" block.

[cdbc]

Hi
Use a record with all the parameters you need and feed that to your thread / calcule-procedure...
If you use 'PostMessage()' for your comms, you shouldn't need synchronization, but YMMV.
...And don't forget -- Gui-code in threads (apart from mainthread) -- is
 an ABSOLUTE NO-GO!!!
The LCL is NOT threadsafe!
Regards Benny

[Xenno]

I usually use a trick to execute a thread which I need to wait it to finish. I use a "Please wait" form that is called with ShowModal. This form's onShow event I create and run the thread.

When the thread finished, this form will handle by thread's onTerminate for example. Then, the form close itself and return ModalResult (eg. mrOK or mrCancel) based on thread result.

This way, the app won't get Not Responding flag from OS while the UI is blocked. It can be extended to allow aborting the thread execution.

[Thaddy]

A modal form is blocking for the main thread....
If the modal form is IN the thread, cdbc' s warnings apply.
TThread has class methods that can report back status, if required.
This is not difficult at all.
See the examples in the manual:
https://www.freepascal.org/docs-html/rtl/classes/tthread.executeinthread.html

[Xenno]

A modal form does not block the main or caller thread itself—it only blocks the UI of the main or caller form. This is why the operating system does not mark the application as Not Responding and protecting something for example unexpected button click in main form while the thread is still running.

The typical flow looks like this:

FormMain -> FormProgress -> WorkerThread -> FormProgress -> FormMain

FormProgress can display status or progress updates using a synchronized method from the running worker thread, while also providing a chance for user to cancel or terminate the worker thread. 

I’ve been using this technique, for example, when loading large files, and it works well to keep the UI responsive while still allowing cancellable background processing.

Anyway "progress dialog" fits perfectly for modal form. But, yes, this is only a suggestion.

[Phoenix]

Hi
Use a record with all the parameters you need and feed that to your thread / calcule-procedure...
If you use 'PostMessage()' for your comms, you shouldn't need synchronization, but YMMV.

Yes, with a pointer you can pass everything (as placed in the code even if in the case of the test it is not needed). You just have to add more code for each use, but you can't do it otherwise, putting the calculations in the thread.

...And don't forget -- Gui-code in threads (apart from mainthread) -- is
 an ABSOLUTE NO-GO!!!
The LCL is NOT threadsafe!

Of course, this is just some preliminary code for testing.

I usually use a trick to execute a thread which I need to wait it to finish. I use a "Please wait" form that is called with ShowModal. This form's onShow event I create and run the thread.

When the thread finished, this form will handle by thread's onTerminate for example. Then, the form close itself and return ModalResult (eg. mrOK or mrCancel) based on thread result.

This way, the app won't get Not Responding flag from OS while the UI is blocked. It can be extended to allow aborting the thread execution.

Thanks @Xenno. The goal here is to automatically display a waiting form, but only when the calculation time exceeds n seconds. Otherwise, I find it annoying to have it disappear instantly or have to slow it down. In any case, the most annoying thing is seeing the dialog when it's not needed. This compensates, for example, when a user uses the program on a faster or slower computer.

A modal form is blocking for the main thread....
If the modal form is IN the thread, cdbc' s warnings apply.
TThread has class methods that can report back status, if required.
This is not difficult at all.
See the examples in the manual:
https://www.freepascal.org/docs-html/rtl/classes/tthread.executeinthread.html

Yes, the examples are clear. Thanks @Thaddy.

A modal form does not block the main or caller thread itself—it only blocks the UI of the main or caller form. This is why the operating system does not mark the application as Not Responding and protecting something for example unexpected button click in main form while the thread is still running.

The typical flow looks like this:

FormMain -> FormProgress -> WorkerThread -> FormProgress -> FormMain

FormProgress can display status or progress updates using a synchronized method from the running worker thread, while also providing a chance for user to cancel or terminate the worker thread. 

I’ve been using this technique, for example, when loading large files, and it works well to keep the UI responsive while still allowing cancellable background processing.

Anyway "progress dialog" fits perfectly for modal form. But, yes, this is only a suggestion.

With the current implementation, I should also keep user actions "blocked." Given the use of "Application.ProcessMessages," a user tired of waiting might click around, causing problems  .

[Thaddy]

A modal form does not block the main or caller thread itself—it only blocks the UI of the main or caller form.

This is plainly not true, at least on Windows. It blocks the thread it is running in, usually the main thread completely, not only GUI elements.

[cdbc]

Hi Phoenix
As promised, here's a little project for you to play with...
It sort of works  Haven't gotten the delayed showing of progress to work yet though  ...I t shows right away 
Regards Benny

[Phoenix]

As promised, here's a little project for you to play with..

Thanks for this implementation 

Here I'm using Windows 10 with Laz 3.6 FPC 3.2.2 and it doesn't work properly. In particular, it stops almost at the end, not completing the button re-enablement, and it doesn't hide the dialog. I tried a couple of codes, but what makes it work is adding a sleep() like this:

Code: Pascal  [Select][+][-]

1. function Calc(aHandle, n: ptruint): ptruint;
2. var
3.  i: LongInt;
4. begin
5.  Result:= 1;
6.  for i:= 2 to n do begin
7.   Result:= Result+i;//("+" just to avoid overflow for the generic test)
8.   if i mod 200000 = 0 then
9.   begin
10.    PostMessage(aHandle,LM_ThreadUpdate,n,i);
11.    Sleep(100);//<--
12.   end;
13.  end;
14. end;
15.  

It sort of works  Haven't gotten the delayed showing of progress to work yet though  ...I t shows right away 

Don't worry . Perhaps keep the dialogue hidden, record the time at startup, and check with each update whether it's time to show the dialogue. Even if it's less precise, you avoid using an additional thread.