MsgBox displaying BEHIND Window1

Weird problem. I have a long-standing app that I am updating to 64 bit, Retina and a few other bits.
When app starts up, it loads Window1 with a listbox, loads with data and a bit of listbox formatting (cellbackgroundpaint and celltextpaint). A MsgBox is then displayed with simple text string telling user data is ready.

App working beautifully (ie as expected) on OSX - msgbox displays, user clicks OK and on we go.

On Windows I have a problem: the MsgBox is displayed BEHIND Window1 (I can sometimes see it flash up, then covered by Window1). So the entire app hangs, waiting for user to click OK. Its modal, so nothing else can happen until OK is clicked. But OK can’t be clicked because the entire message box is hidden behind Window1. Can’t even move Window1 to show the MsgBox. I can’t even kill the app with the debugger, have to use Windows Task Manager.

What would make a MsgBox display behind a Window? I call the MsgBox after all other processing is done, so no methods working in background. I’m not familiar with threads, but there shouldn’t be anything else going on at this point. Window1 is the only active window at this point. My MsgBox is a standard Xojo call, nothing modified, and it is called by a method belonging to Window1.

I should add, my Mac is current, high-end machine. My Windows test machine is deliberately low-spec to test my app on a computer that many of my customers might use. Would the slowness of the Windows machine be the issue - ie still processing Window1 after displaying the MessageBox?

Do you use something like self.WinTopMostWindowMBS = true ?

The only MBS plugin I use is DynaPDF. I am not doing anything to artificially process the display of Window1, except to position it at Open, long before the msgbox is called.

Also, first time compiling with Xojo 2018 1.1, and using Windows-recommended way of installing Universal Runtime.

Just trying to think of any differences I have made since my last release of this app (late 2016).

This will not resolve your trouble, but using a MsgBox for that is to be avoided. For that, you can add a Label at the window bottom and place there the UI text.

Here, MsgBox OK button have or not the focus (is the default button or not !) depending on the wind origin or the captain # of years or… you see what I mean.

Put a short period timer on the Window1 and open the msgbox from the timer. This will allow window1 to complete opening and the msgbox will show on top

You could try MessageDialog instead of MsgBox.


Do you do anything with focus changes, timers that update content after the message box is shown?
What Frame Type is the window, Document (default)?
Do you use any windows specific declares?
This is in 2018r1.1 right?
Are you able to replicate it in a simple project?

What’s the Type of Window1?

[quote=395111:@Rob Lang]Its modal,[/quote] ?

That is referring to the msgbox

Ah! Sorry, thank you. :slight_smile:

Right. I’m wondering if Window1 is set to Sheet, Modal or MovableModal which might cause this.

Thanks for the thoughts.

Window1 is a default Document window.
No timers or focus changes after msgbox displays. The msgbox is the last line of the method.
No windows-specific declares.
yes, Xojo 2018r1.1

I will try a simple window-msgbox project under the same compile conditions.


Give Windows Focus Logger a try (the GUI exe is fine, just launch it and hit Start) and double check that you are only getting one focus event for the opening of Window1 and one event for the opening of the MsgBox and that it’s not raising an event for the return to Window1 until you OK the MsgBox

Thanks Julian - I’ll give it a try if my next hunch fails:

I’ve narrowed it down - all my msgboxes are hidden behind Window1 after a certain part of my code. That code is a HTTPSocket.Get within Window1 that tries to get the version number from my server (a simple txt file). Before that socket triggers, msgboxes display as expected. After the socket tries, all further msgboxes are hidden behind window1. The socket successfully retrieves the file, but maybe Window1 continues to get focus because I’m not closing my socket? I’ll try closing the socket and see if that helps.

Scratch that - disabled my sockets, and msgbox still displayed behind window. ???

If I resize window1 so that it doesn’t cover the middle of the screen, then message box is displayed properly, above Window1.
But If Window1 is resized so that it covers most of (>75%) where the mesgbox will go, the msgbox is displayed behind Window1.

A simple example project that shows the problem would be really helpful right about now.

OK Ill see if I can strip project to its bare essentials, but still display problem.

I’m not 100% sure, but I think I found the issue. I was stripping my project down to its barest elements, while retaining the bug, so I could post the project it here.

My listbox has a CellBackgroundPaint event that included this line

Me.ColumnAlignment(2) = Listbox.AlignLeft

If I remove this line, the message box works fine. With this included, msgbox shows behind Window1. Debugger shows no errors.

My listbox is defined with 11 columns, but empty of data. Why would this throw an error only when a message box is displayed? And why only on Windows?

Stripped-down project here. Hit the “Hit Me” button at top left to fire a msgbox that hangs the app on Windows.