forums.silverfrost.com

wahorger · Joined: 13 Oct 2014 Posts: 1257 Location: Morrison, CO, USA

In adding some functionality, it occurred to me that it is possible (likely??) that if one is using both %sc to init the window, and %mv to allow the user to move the window, the order of execution of these at window creation could be indeterminate. Meaning that there is no guaranteed sequence. For example, %mv always followed by %sc.

So I thought I'd ask here, and if it is indeterminate, how you handle it.

PaulLaidler · Posted: Thu Feb 13, 2020 8:51 am Post subject:

You can track the events by getting the callback "reason" from within the callback function. The %sc callback provides "WINDOW_STARTUP" whilst the %mv callback provides "WINDOW_MOVEMENT".

wahorger · Joined: 13 Oct 2014 Posts: 1257 Location: Morrison, CO, USA

Thanks, Paul! This is definitely the best way to get the job done!

wahorger · Joined: 13 Oct 2014 Posts: 1257 Location: Morrison, CO, USA

In looking at the sequencing of the REASON returns using a small test program, it would appear that the WINDOW_MOVEMENT starts first, then, WINDOW_STARTUP is processed before WINDOW_MOVEMENT is finished. I discovered this by adding a PRINT statement in the routine, and rather than the CALLBACK_REASON being on two separate lines, they appeared on one line.

Using /SAVE to make sure local variables are static, I added an increment/decrement following the I/O statement. This shows that the WINDOW_STARTUP is executed before the WINDOW_MOVEMENT can finish. I post the code below.

Does this imply that these handlers need to be re-entrant? Or, am I looking at something wrong?

wahorger · Joined: 13 Oct 2014 Posts: 1257 Location: Morrison, CO, USA

It appears that the PRINT allows this to occur. I added in my own stack subroutines and tracked the value of "i" in the callback routine. If the PRINT isn't there, it all works as expected.

PaulLaidler · Posted: Thu Feb 13, 2020 7:30 pm Post subject:

These callbacks are in response to messages in the windows message loop but the callbacks are not always called immediately. Sometimes they are stacked and delayed for a brief time. This is in addition to the fact that messages are sometimes "sent" and wait for an answer and sometimes "posted" without waiting.

If the behaviour that you observe is clearly consistent then OK but as a general rule there could easily be variations in response and order.

wahorger · Joined: 13 Oct 2014 Posts: 1257 Location: Morrison, CO, USA

It might be that the PRINT update to the output window is what allows the second call to the routine before it has had a time to finish. I can deal with that, I think.

PaulLaidler · Posted: Thu Feb 13, 2020 7:30 pm Post subject:

These callbacks are in response to messages in the windows message loop but the callbacks are not always called immediately. Sometimes they are stacked and delayed for a brief time. This is in addition to the fact that messages are sometimes "sent" and wait for an answer and sometimes "posted" without waiting.

If the behaviour that you observe is clearly consistent then OK but as a general rule there could easily be variations in response and order.

wahorger · Joined: 13 Oct 2014 Posts: 1257 Location: Morrison, CO, USA

Paul, thanks for the reply. I've dealt with this "async" behavior in other Windows environments, and while it can be frustrating, if you know its's going to happen, you can deal with it!!

How I am intending to deal with it is to "attach" a TYPE (using %ud) to the window at creation time, with a logical that indicates that the WINDOW_STARTUP event has occurred and been processed, allowing the movement of the window to be handled by a separate routine that only "registers" the movement when startup has fully completed.