Recent

Author Topic: Trouble in GUI event handling  (Read 608 times)

simsee

  • Jr. Member
  • **
  • Posts: 82
Trouble in GUI event handling
« 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.

howardpc

  • Hero Member
  • *****
  • Posts: 3681
Re: Trouble in GUI event handling
« Reply #1 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.

lucamar

  • Hero Member
  • *****
  • Posts: 3779
Re: Trouble in GUI event handling
« Reply #2 on: December 25, 2020, 10:35:30 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.
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

simsee

  • Jr. Member
  • **
  • Posts: 82
Re: Trouble in GUI event handling
« Reply #3 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.

jamie

  • Hero Member
  • *****
  • Posts: 4362
Re: Trouble in GUI event handling
« Reply #4 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.


The only true wisdom is knowing you know nothing

simsee

  • Jr. Member
  • **
  • Posts: 82
Re: Trouble in GUI event handling
« Reply #5 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;

MarkMLl

  • Hero Member
  • *****
  • Posts: 2415
Re: Trouble in GUI event handling
« Reply #6 on: December 26, 2020, 12:25:05 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
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018