Here’s the problem. I have a regular non-modal window. With a PushButton it loads a Sheet Window with ShowModalWithin(self). (Of course there’s no concept of Sheet in Windows, so it’s just a regular Document Window, Modal.) With a PushButton on that window, it loads a Window via ShowModal().
The problem is that on that window (essential this third one showing, and since it’s Modal it’s the principal window), all the buttons don’t do anything if you click them. However, in some instances hitting ENTER or CANCEL, if the buttons are Default and Cancel, will trigger the buttons, but not every time. I don’t know why.
if you flip Window1.Frame from SHEET to DOCUMENT, you’ll see the problem goes away.
And this is not a problem on Mac, just Windows. And there shouldn’t be a problem with cascading Modal windows.
This is with REAL2011r3, but also Xojo 2013r4.3. Perhaps the latest Xojo has fixed it, but I kind of doubt it.
If you close window1 as you go to window3, buttons work.
OR
If you change Window3 to a “movable modal”, buttons work.
To ignorant me it seems both funny and sensible. Normally having a modal window open is going to stop input to other windows - maybe that is what is happening. I would not try having more than one modal window open at a time.
Edit again.
Interesting bit about Modal sheets in Mac OS X here:
[quote=190616:@Garth Hjelte]1) Is this a bug?
2) How would you workaround it?[/quote]
2015R2.2,
This is most definitely a bug.
The workaround I found is to close Window 1 in the “show modal” button. Then MouseDown works in the buttons. But yet, the Action event still does not fire.
Action fires fine in BevelButtons. You may want to switch.
I don’t think you should showModal the document Window3. It is unnecessary. But that is not the cause of the bug.
You should file a bug report. The test project demonstrate it perfectly.
Well, it’s hard to workaround the bug. In my apps, “Window3” is actually a self-made InputBox, so it’s a generic thing, meant to be Modal. I mean that in my particular case I’m looking at, but if it’s true that calling anything Modal from a Sheet Window is going to cause problems, it’s a systemic issue.
Perhaps the right way to frame the question is; should Document windows be called as Modal in the first place? Since it’s a InputBox that is in question here… perhaps the best plan of action is that in designing the interface, any window that is ALWAYS meant to show as Modal show have the Frame=FrameTypeMovableModal, never Document (the default). Even though Document frametype works well being shown as Modal, here’s an instance - though it’s a bug - where it doesn’t, so perhaps I should switch all my Modal-only Windows to FrameTypeMovableModal, and that would “fix” the bug by “doing the right thing” ?
And the bummer thing about a bug NOW is that it’ll NEVER be applied in PPC, or OSX 10.6 or lower, or XP. This bug has been around forever, interestingly. (Perhaps because people are smarter to not simply live with FrameTypeDocument.)
[quote=190659:@Garth Hjelte]Well, it’s hard to workaround the bug. In my apps, “Window3” is actually a self-made InputBox, so it’s a generic thing, meant to be Modal. I mean that in my particular case I’m looking at, but if it’s true that calling anything Modal from a Sheet Window is going to cause problems, it’s a systemic issue.
Perhaps the right way to frame the question is; should Document windows be called as Modal in the first place? Since it’s a InputBox that is in question here… perhaps the best plan of action is that in designing the interface, any window that is ALWAYS meant to show as Modal show have the Frame=FrameTypeMovableModal, never Document (the default). Even though Document frametype works well being shown as Modal, here’s an instance - though it’s a bug - where it doesn’t, so perhaps I should switch all my Modal-only Windows to FrameTypeMovableModal, and that would “fix” the bug by “doing the right thing” ?
And the bummer thing about a bug NOW is that it’ll NEVER be applied in PPC, or OSX 10.6 or lower, or XP. This bug has been around forever, interestingly. (Perhaps because people are smarter to not simply live with FrameTypeDocument.)[/quote]
You should certainly not showmodal a document window. But this is not the cause of the bug. For a general use dialog, you should indeed use MovableDialog if you want to keep the window bar. Then the bug goes away. I do not think it should be a problem in XP.
I don’t know if this is the same issue you are having, but I have had some issues which were solved by opening the dialog from a timer.
e.g., if I had one window open a second window, and the second window opened a modal dialog, I would have the modal dialog opened by a timer (and if that doesn’t work, try opening the second dialog via a timer as well).
I tried some things and generally dialogs that I know will ALWAYS be shown as Modal I change to FrameTypeMovableModal and that seems to work for Windows and Mac.
The only problem I encounter is that sometimes I want a Unified look to the dialog,a dn the code I use messes with FrameTypeMovableModal, so the above is not a universal solution. Since the ‘Frame’ property is not runtime changable (understandably) I have to make two dialogs with two different frames. Fortunately ContainerControls save the day here.
And I don’t like a Close-Max-Min buttons on the title bar on Modal dialogs most of the time anyway.
I’ll put in a Bug Report if I can - my license isn’t current and it almost never is.