Lazarus

Programming => LCL => Topic started by: simsee on December 25, 2020, 10:00:51 pm

Title: Trouble in GUI event handling
Post by: simsee on December 25, 2020, 10:00:51 pm
Suppose we have a GUI application with two forms (i.e. Form1, Form2), for which the OnShow event is handled as shown in the following code snippets:

Code: Pascal  [Select][+][-]
  1. procedure TForm1.FormShow(Sender: TObject);
  2. begin
  3.   writeln(1);
  4.   Form2.Show;
  5.   writeln(5);
  6. end;

...

Code: Pascal  [Select][+][-]
  1. procedure TForm2.FormShow(Sender: TObject);
  2. begin
  3.   writeln(2);
  4.   writeln(3);
  5.   writeln(4);
  6. end;

The result obtained from the console is 1 2 3 4 5. This means that in TForm1.FormShow, the statement following Form2.Show (i.e. writeln (5)) is executed only after the conclusion of the TForm2.FormShow procedure. Is this sequence of operations guaranteed?

Thanks in advance for the support.
Title: Re: Trouble in GUI event handling
Post by: howardpc on December 25, 2020, 10:33:39 pm
In a single-threaded application statements are executed strictly in the logical  order in which they are coded.
If this were not the case, no one could reliably write any  application, however simple or complex.
Title: Re: Trouble in GUI event handling
Post by: lucamar on December 25, 2020, 10:35:30 pm
Quote from: simsee on December 25, 2020, 10:00:51 pm
Is this sequence of operations guaranteed?

Yes ... more or less. It has a very high likelihood of being always that way but it's not exactly guaranteed for all possible combinations of target OS/processor, though I can't think ATM of one where it would fail. That is, that it happens is system-dependent but most (all?) current systems behave that way.
Title: Re: Trouble in GUI event handling
Post by: simsee on December 25, 2020, 11:05:13 pm
I forgot to say that the context is single threaded. My question is actually more general: in the hypothesis of single threaded application, is the instruction following the one that triggers an event executed only after the conclusion of the handling of that event? I believe that your answers also respond to my broader question.
Title: Re: Trouble in GUI event handling
Post by: jamie on December 26, 2020, 12:51:07 am
The SHOW method is a direct call to the code that would otherwise get called if and when it receives a WM_SHOWWINDOW or in Lazarus hood, LM_SHOWWINDOW

 That is true for windows, on Linux however, I think they emulate the same process via a message que, for example a WM_ACTIVATE. That message is first sent to the window that is losing its attention and also has in the message the new window getting the attention and then it gets sent to the window being activated.

 But these messages are on a posted que when done that way

 If you were to use the ShowWindow API it would post these messages which would mean most likely your order would end differently

 1,5, then 2,,3,4 because the messages aren't handled until you exit your code and have it return back to the message pump.


Title: Re: Trouble in GUI event handling
Post by: simsee on December 26, 2020, 11:46:21 am
A simple solution to guarantee the execution of the instructions in the expected sequence could be the use of a sort of semaphore. For the previous example:

Code: Pascal  [Select][+][-]
  1. procedure TForm1.FormShow(Sender: TObject);
  2. begin
  3.   writeln(1);
  4.   Form2.Show;
  5.   repeat until Form2.Shown;
  6.   writeln(5);
  7. end;

Code: Pascal  [Select][+][-]
  1.   TForm2 = class(TForm)
  2.     procedure FormShow(Sender: TObject);
  3.   private
  4.  
  5.   public
  6.     Shown : boolean;
  7.   end;

Code: Pascal  [Select][+][-]
  1. procedure TForm2.FormShow(Sender: TObject);
  2. begin
  3.   Shown:=False;
  4.   writeln(2);
  5.   writeln(3);
  6.   writeln(4);
  7.   Shown:=True;
  8. end;
Title: Re: Trouble in GUI event handling
Post by: MarkMLl on December 26, 2020, 12:25:05 pm
Quote from: lucamar on December 25, 2020, 10:35:30 pm
Yes ... more or less. It has a very high likelihood of being always that way but it's not exactly guaranteed for all possible combinations of target OS/processor, though I can't think ATM of one where it would fail. That is, that it happens is system-dependent but most (all?) current systems behave that way.

I think you could improve it by putting Flush(Output) after every Write() or WriteLn(); and Application.ProcessMessages after the Show.

However I'd strongly advise against making any assumptions about your program being single-threaded, since you never know what bright ideas the OS or hardware developers will have in the future.

MarkMLl
TinyPortal © 2005-2018