Secondary form does not refresh

[wschulte]

 When I open a secondary form, write some lines to a memo on it and then start a lengthy operation, the secondary form show up only AFTER that lengthy operation ends. That is despite processmessages calls just before the operation.
In the attachment I made an example. If I click [Process] the message is displayed on the memo, the operation is performed, and the end message is written. But if I press [To form] the secondary form shows up all grey and displays all messages AFTER the operation ended. That is not what I want: I want the start message to be visible BEFORE the operation starts.

What am I missing here ?

Lazarus 3.0 (2024-02-28), FreePascal 3.2.2 on Linux mint 21.1

[TRon]

When I open a secondary form, write some lines to a memo on it and then start a lengthy operation, the secondary form show up only AFTER that lengthy operation ends. That is despite processmessages calls just before the operation.

processmessages should also be called during (and inside) the lengthy process.

In the attachment ...

Unfortunately, no attachment.

What am I missing here ?

Perhaps the attachment, just like me ? 

PS: if you are unable to attach your project then you can obtain information here on how to do that

[wschulte]

Thanks for the reply. The attachment .. oh my, I forgot it  , but not this time.

The problem is that in the case I stumbled on this, the lengthy process is out of my hands: the creation of a TCSVDocument. This is in this case a very lengthy process (as in 30 seconds and more) and I am heitant to change the component.

Mind you, in the test case I just do a stupid loop. But it shows the behavior I see,

[cdbc]

Hi
Would it be possible for you to call the /lengthy operation/ in an anonymous thread?!?
That way, you'd have your hands(read forms) free to do other things...
Regards Benny

[wschulte]

cdbc
« Reply #3 on: Today at 08:44:17 am »
Would it be possible for you to call the /lengthy operation/ in an anonymous thread?!?

I have been thinking about that. It is quite possible, but I am not so well known with threads. I think I will have to solve it that way.

I assume you mean with an anonymous thread just a TThread object .. ?

[TRon]

First change this:

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

1. while (index >= 0) do
2.     index := index -1;
3.  

into this

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

1.   while (index >= 0) do
2.   begin
3.     index := index -1;
4.     Application.ProcessMessages;
5.   end;
6.  

for both loops

Then realize that you wait for a key to be pressed on form2.... but what component is actually active ? indeed, the memo. So use the memo's keypress event 

That will at least make your program more responsive. You can worry about details later.

And yes, as suggested by cdbc when there is no other way then using a thread comes to mind.

[wschulte]

In replay #5 TRon wrote:
Code: Pascal
  while (index >= 0) do
  begin
    index := index -1;
    Application.ProcessMessages;
  end;
 
for both loops

The first loop (that is under the button [Process]) doesn't need the ProcessMessages: it displays the start anyway before the loop starts. That's what puzzles me, as it doesn't do so in the second loop (under the [To form] button).
In the original case I haven't any control over the loop (opening a large csv-document with TCSVDocument).

For now I will follow cdbc's suggestion to do it in a thread.

[TRon]

In the original case I haven't any control over the loop (opening a large csv-document with TCSVDocument).

Ah ok. Yes, in that case better use a thread as suggested by cdbc.

It is not that difficult to use threads, see for example wiki here. If you do not need to do anything special (other than loading a document) then it is fairly easy as f.e. you can use your main program thread to display a timer/busy signal to the user during loading.

Strike that, User KodeZwerg hinted me in another thread related thread  to have a look at TThread class... I did not know that the class was extended to have cool things like this. Plain and simple 

[MarkMLl]

One word of warning here. Be very careful about scattering Application.ProcessMessages throughout the main thread of a program in an attempt to keep things running, and also putting Synchronize(shim) in a background thread so that e.g. a progress bar is updated.

If the shim calls something with an A.PM in it, you've got a potential recursion which can be somewhat difficult to track down if you're not alert to the possibility.

MarkMLl

[TRon]

One word of warning here.

Yes indeed MarkMLI. Thank you for the reminder.

Because I had no idea of the original goal of TS, my goal was to try and attack it brutally (but wrong) to try solve the issue. If that works then details can then be addressed using a more sane approach. Initially I missed the bigger picture.

[wschulte]

One word of warning here. Be very careful about scattering Application.ProcessMessages throughout the main thread of a program in an attempt to keep things running, and also putting Synchronize(shim) in a background thread so that e.g. a progress bar is updated.

If the shim calls something with an A.PM in it, you've got a potential recursion which can be somewhat difficult to track down if you're not alert to the possibility.

MarkMLl

Thanks for that. But what is an "A.PM" ?

[wschulte]

So .. tried to process the CSV file in a thread, but still the secondary form is updated only AFTER the thread is finished 

I changed the test program a bit, so it does what the real life case does (open a CSV document) and in a thread or not. It is in the attached zip file.

What keeps me bothering is the difference between doing all without opening a secondary form (messages are shown instantly) and with a secondary form (messages show only AFTER). I keep the feeling I am missing something here ...

BTW. in the real life case it is much worse: after opening the CSV document a database processing is taking place. This takes a lot of time, so the user is staring at the gray secondary form for a while.

[MarkMLl]

One word of warning here. Be very careful about scattering Application.ProcessMessages throughout the main thread of a program in an attempt to keep things running, and also putting Synchronize(shim) in a background thread so that e.g. a progress bar is updated.

If the shim calls something with an A.PM in it, you've got a potential recursion which can be somewhat difficult to track down if you're not alert to the possibility.

Thanks for that. But what is an "A.PM" ?

Look one para further up: Application.ProcessMessages. It's the call you've got to make occasionally, rather than having your main thread in a tight loop waiting for thread completion.

Oh, and para is a frequently-used abbreviation for "paragraph".

MarkMLl