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.

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'.

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

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?

    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

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.

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.

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.

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.

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.