View previous topic :: View next topic |
Author |
Message |
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Wed Feb 12, 2020 11:12 pm Post subject: Which is first, %sc or %mv? |
|
|
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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
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". |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Thu Feb 13, 2020 3:09 pm Post subject: |
|
|
Thanks, Paul! This is definitely the best way to get the job done! |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Thu Feb 13, 2020 5:55 pm Post subject: |
|
|
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?
Code: |
winapp
integer i
integer,external:: start_window
print *,'Started'
i = winio@('%ww%sc%mvHello There%bt[done]',start_window,start_window)
end
integer function start_window()
use mswin
integer:: i=0
i = i+1
print *,trim(clearwin_string@('CALLBACK_REASON')),i
start_window = 1
i = i - 1
return
end
|
|
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Thu Feb 13, 2020 6:06 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
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. |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Thu Feb 13, 2020 7:30 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
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. |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Thu Feb 13, 2020 7:40 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Fri Feb 14, 2020 12:48 am Post subject: |
|
|
“We never know what is going to happen, do we? Life is always throwing us this way and that. That’s where the adventure is. Not knowing where you’ll end up or how you’ll fare. It’s all a mystery, and when we say any different, we’re just lying to ourselves. Tell me, when have you felt most alive?” _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... " |
|
Back to top |
|
|
|