MsgBox in Modal Window open event defers modal window visibility, and I don't want that!

I’m using Xojo2016R3 with Win7.

I have a main Window1, which calls modal Window2.
In the open event of Window2, I have a simple MsgBox.

Window1, btnOpenModal Action Event:

Window2.ShowModal

Window2 Open Event:

MsgBox ("Window2 should now be shown - but it doesn't, until I select the OK button... bummer!!")

Window2 does not become visible UNTIL the OK button is selected in the message dialog.

This issue seems similar to a previous window focus issue I had, but it’s not the same. That issue was resolved using Xojo.Core.Timer.CallLater. I’ve looked at it but can’t/don’t know if that can solve my current issue.

It’s not a big problem, the app still works fine, but it does leave the user confused because they do not see Window2 behind the MsgBox.

Any ideas?

In fact, I think that there is not a problem of Modal window.
No window is shown until Open event module has finished.
Even, the first time, the Activate event must have finished to show the window.
Not sure if there are more events to be finished before showing the window.

Well when you put it that way, it makes sense.

So I wonder if using a timer in Window2 would achieve the result I want - I guess there’s only one way to find out.

After evaluating in a small test project, it appears that using a Timer has solved the issue.

Window1, btnOpenModal Action Event:

Window2.ShowModal

Window2, Open Event:

Timer1.Enabled = True

Timer1 in Window2 is set to Single with a period of 250ms, which isn’t too much of a delay.

Timer1 Action Event:

MsgBox ("Well, well, well - isn't that a lot better!!")

Like I said, it seems to work fine. However, I do wonder what would happen if the window (window2) took a while to draw up. Would it show a half drawn window with the MsgBox over the top? or does the timer event only fire once the window is completely drawn?

Here you go Steve.

Use the Activate event which fires when the window is actually open and receives focus. To stop it firing if you move off the window and back on again use an “opening” boolean which you set during the Open event and check for and clear inside the Activate event. The code will then only fire when the window is opening and is actually shown to the user.

https://www.dropbox.com/s/hkdsvy25ttt4bun/TestActionOnWindowOpen.xojo_binary_project?dl=1

No timers were harmed in the writing of this code :slight_smile:

[quote=411854:@Steve Kelepouris]I’m using Xojo2016R3 with Win7.

I have a main Window1, which calls modal Window2.
In the open event of Window2, I have a simple MsgBox.

Window1, btnOpenModal Action Event:

Window2.ShowModal

Window2 Open Event:

MsgBox ("Window2 should now be shown - but it doesn't, until I select the OK button... bummer!!")

Window2 does not become visible UNTIL the OK button is selected in the message dialog.

This issue seems similar to a previous window focus issue I had, but it’s not the same. That issue was resolved using Xojo.Core.Timer.CallLater. I’ve looked at it but can’t/don’t know if that can solve my current issue.

It’s not a big problem, the app still works fine, but it does leave the user confused because they do not see Window2 behind the MsgBox.

Any ideas?[/quote]

This makes perfect sense since MsgBox is synchronous. In the Open event when you show it the Open event code is paused until you press OK or Cancel and then the open event code carries on and eventually finishes the Open event - and then the modal window shows up.

I’ve had some computer problems in the last 2 weeks which means I haven’t been able to test method, but have no doubt it works.

The last 2 weeks without working on my app has almost caused me to lose the “context” of the point of why I asked this question in the first place.

I’ve got written notes and will have to review those, I’m sure I’ll come back to what the point was. Yes, the point was being able to “see” the window underneath, but why I thought that was important in my application needs further review, but writing it out now helps.

The purpose is that the User could at least “see” what window was underneath, and therefore feel confident they had some idea of what would happen next. Even though it’s a simple message box and therefore “no way out” except to select OK, they can at least see what will happen next. :slight_smile:

I know it seems absurd. But this situation would only happen very very rarely in a “setup” scenario. My view is that if the user “sees” the window below, then that is better than not knowing what is going to happen next. Even though they have NO choice but to select OK, they at least “feel” a sense of comfort in what will happen next.

I appreciate the Code and the Coders, but there is also a “philosophy” of programming.

No, you don’t have to fear anything. I would guess even a timer delay of 0 ms would be sufficient for your purpose. I use a timer.calllater with a 0 ms delay often in (declared) classes and controls, and it works perfectly in simulating a “Shown” event when triggered from within the constructor.

After the open event fired, the window is marked for drawing, and that is the first thing the system will do. After that, the system goes into the main loop, and that’s where the timer will fire.

It was so you could open a msgbox during a window opening but it was stopping the open mid tracks. As Ulrich mentions, a calllater with 0 ms would be fine because it’ll fire that once it leaves the Open.

I ended up using the timer method (from my first post Oct29) and it works as expected, as in, it does the job I want it to.

However, I reckon the “callLater” and “Window Open Activate” methods are likely more elegant solutions, and I should try to understand them more, but at this stage I’m happy enough with my current method and therefore must forge on with other things.

Afterall, the situation in which this occurs in my software is very rare, so I can’t foresee any unintended consequences, as apposed to the intended ones :slight_smile: