Modal Window appears behind main parent window

I have this code:
Dim winNew As New frmClientInfo
winNew.ShowModal

Where frmClientInfo is set to Modal.

When that is executed many times the client info window pops up BEHIND the main application window.

Shouldn’t it always pop up in front if it’s Modal?

What is ShowModalWithin do?

What does the window Behavior set to Parent vs. Default do?

I have tested variations and it still pops up BEHIND the main window “sometimes”. It is not consistent.

After more testing… if I have a graph open on main window… the frmClientInfo pops in front as expected.

If I have the sGRid visible on main window… looks like it starts redrawing the grid and then a blip and the frmClientInfo pops behind the main window.

Does that have to do with LockDrawing = True and then after loading grid set it back to false?

As in maybe that’s not happening and that’s why it starts to redraw before frmClientInfo windows gets loaded…

[quote=312997:@Tim Turner]
What is ShowModalWithin do?

What does the window Behavior set to Parent vs. Default do?[/quote]
Answers to both of these can be found in the manual.
http://documentation.xojo.com/index.php/Window.ShowModalWithin

http://documentation.xojo.com/index.php/Window.Placement
(Play with each setting to see where it goes, there’s no better way to describe it.)

I can only imagine that your ShowModal issues stem from a cluster of race conditions.

ShowModalWithin does nothing special in Windows.

The Window.Placement documentation…

0 = Default (what is default? Upper left?)
1= Parent Window (does that center it on the parent window? or align with top of parent window)

Regardless playing with Placement setting does nothing to help my problem.

I am still having this problem. The ShowModalWithin won’t help as Michel pointed out.

Should I make it a sheet window which would force it on top of main window???

frmClientInfo has parent ElasticWindow.
frmWorksheet is the main app window.
Should frmClientInfo have parent frmWorksheet?? or would that try to overwrite all the controls on frmClientInfo from frmWorksheet?

If I assume you are correct and that is the problem, how do I debug? Why does it work sometimes and not others?

Maybe sGRid is “fighting” for the focus. Does sGRid contain some parameter that indicates when it has finished loading?

Langue I don’t see such a parameter. There are many many parameters and methods for it though. I was thinking “DrawComplete” or something like that but I don’t see one.

I’m not sure that’s 100% the issue bc I have gotten it to occur with the graphs and not the spreadsheet. So it might be related to drawing the main windows. I am a bit baffled bc I thought just setting the other window to modal would do the trick.

Unfortunately I cannot release my app until I figure this problem out!!!
Because otherwise when they open a file the client info screen is hidden and the user would have no idea where it was.

DOH!!!

Is ShowModal supposed to put that window in front no matter what?

Or does it have to be the child of the window it is in front of? Does that have to do with it at all?

Tried a bunch of options and Movable Modal and Sheet behaved nearly identical (they both show on top of main window and do not allow access to the window behind it). I also added a Canvas and drew a different picture on the backdrop every second; the Movable Modal and Sheet windows still behaved as expected.

What happens if you replace the frmClientInfo by some generic window which is either Movable Modal or Sheet; does it still behave the same?

Unfortunately, I’ve seen this happen in lots of Windows apps. It’s very frustrating when an error message pops up behind the window. It looks like the app has crashed because you can’t do anything. It just beeps at you. It even happens to msgbox sometimes.

[quote=313059:@LangueR]What happens if you replace the frmClientInfo by some generic window which is either Movable Modal or Sheet; does it still behave the same?
[/quote]

The more testing I do the more I see this happening… even with other windows that I have set as Movable Modal like my frmPrint window. I just saw it open behind my main window where you can’t see it.

This is very frustrating… I have bet the farm on this release and this is not really useable with this modal window problem.

For my frmClient window I set the main window to visible = false and then set it back to true after they close the client window.

I could do the same for every other modal window but that’s a bit kludgey… and not even sure I can pull that off in every instance.

If you use Monkeybread Software plugins you could try WinTopMostWindowMBS in their Win plugin. Use it in the window’s Open event and it will force the window to stay in front until the property is set to False. I have found it to be very useful.

I gather you only see the behavior on this particular application and not on other ones you have done. You mention SGrid; is that StyleGrid? I thought that was not compatible with Xojo. I just can’t help to think you are having issues with a special subclassed window which may be having issues “behind the scenes”. Maybe you can create a private ticket to Xojo and submit your project (to them).

I most often see this in the Xojo IDE. The “Build - Progress” dialog is sometimes in the back behind the IDE window, sometimes in Front (but not focussed), and sometimes it is in front and focussed (such as expected).

Richard is probably using this as a way to improve the(maybe not quite optimal behavior of the xojo framework: Window.Topmost Property

Use a Floating window with

beep self.show
in the deactivate event.

[quote=313115:@Michel Bujardet]Use a Floating window with
beep
self.show
in the deactivate event.[/quote]

Do you have to have the beep to make it work?

You may have just saved my life… YES I have the MBS plugins and will try that immediately as well.

The beep is part of the natural behavior for a Modal. It lets the user know why the window pops back to the front. Michel included it to replicate the functionality of a real modal dialog.

Unfortunately race conditions are very hard to debug, especially if you don’t know where the race is starting. The fact that Tim H has seen it with MsgBox though makes me concerned that this could be a Windows issue.

Indeed there is an issue with modal not always taking the front under Windows. But I strongly suspect it could be a Xojo issue, since it is possible to bring the window to front with TopMost.

It is DEFINITELY a Windows issue because it does not occur on the Mac and I am using the same codebase on both with just a smattering of platform specific adjustments.

Also if we add that to the Window Open Event do we need to wrap it with #if TargetWin32 … # end if
since it’s an MBS Win function? Or does it automagically get ignored on the Mac? Obviously I will test that (later when I get back to my mac) but just thought I’d ask.