LiveCode Forums.

Not sure how to reproduce this one so posting it here.

LiveCode Community 9.6.2 rc3; Ubuntu 20.04.2 LTS.

I tried to close a stack by clicking on the close button in its title bar. I got a dialog box asking whether to save changes first and said yes. Then another box appeared saying words to the effect of "Saving the stack; please wait". This box had no buttons or other ways to dismiss it, and it just stayed there.

It turned out that the "please wait" box was floating above and entirely obscuring a dialog box with an error message, which required a click on its OK button before anything else would happen. When I managed to work that out I was able to reveal the error dialog by moving the stack window, which took the error dialog with it while leaving the floating window in the same place.

In the end I managed to recover the situation but I think it's perhaps less than ideal to allow floating status messages to hide error dialogs...

Yeah, I see this fairly frequently.
Did you file a bug report?

Hi.

Never seen this on my Mac. Mark, do you work in Linux?

Craig

You'll frequently see this when saving a stack in a previous file format. The dialog about whether you want to save in the previous or current format is often hidden behind the "saving..." pane. Not all the time, but often enough to be annoying.

Interesting. I'm now wondering whether this is a case where LC asks the window manager to do something (like "bring this dialog to the top") and the window manager refuses to comply - yet LC carries on under the assumption that the request was acted on.

Could this be related to the known problem that under [at least some versions of] Linux you have to disable the backdrop before the IDE will behave nicely?

@dunbarx has said this doesn't happen on Mac. Has anyone seen it under Windows, I wonder?

It's possible.
For the backdrop thing LC issues a request to the window manager to change the z-ordering of windows. For *most* linux window managers that works, but not for (at least) mate. And it's actually up to the window manager whether or not to accept the request - that's the way that mechanism works.

So possibly the same thing is happening with the two dialogs, although the backdrop thing works for me on linux mint and I still occasionally (not always) see the hidden save dialog if I'm saving a stack in a legacy format, so that may just be a red herring.

It's a bug that only happens on Windows (and maybe Linux I guess).
https://quality.livecode.com/show_bug.cgi?id=8717

Thanks for those replies, and Jacque: I hadn't seen that bug report so thanks for that in particular.

I don't know whether what I'm seeing is related to that bug report or not, but I have now found a recipe that enables me to demonstrate what I'm seeing. The recipe is:
1. Create a new stack at the default size.
2. Drag a new button onto the stack so that there'll be something to save.
3. Choose File -> Close and Remove From Memory.
4. A dialog box asks whether you want to save the stack first. For me, this screenshot shows the dialog. Notice that the dialog has appeared in front of the LiveCode main window but behind the stack, and the stack still has the focus. 5. In the dialog box, click Save. A new dialog box asks you to name the file, so do that.
6. A further dialog box now appears, asking you to confirm that you want to remove the stack from memory. Here is the screen shot showing this box. Notice that this box appears in front of the stack window and has taken the focus. I would expect both those dialog boxes to appear in front of everything and to grab the focus.

This is with LiveCode Community 9.6.2 rc-4, running on Ubuntu 20 LTS with the Gnome window manager.

I wonder whether any kind souls might be willing to try this on other platforms to see whether it's common?

On Mac this never happens, the dialogs are always at the front. On Windows it only happens if the stack is not a toplevel stack when the dialog is called. It's odd that in your case it only happens the first time but not the second.

I do think it's related to the same bug though, and I'd add my comments there. The problem seems to be which stack regains focus when the dialog appears.

Following your recipe there I get (linux mint 20 with cinnamon desktop manager)

the save dialog appears as a "sheet": a dialog box whose top is aligned with the top of the stack to be saved, and is right- or left-aligned with the edge of the stack to be saved, depending on whether there is enough space to one side or the other. Also, if the tools palette would interfere with reading the text of the dialog box, the tools palette is moved out of the way.

Again, many thanks to you both!

I think I might try to explore the engine source code to find out why two supposedly similar dialogs behave in different ways on my system. This may take some time...

If it's anything like the patch I made to get the backdrop working, grep for calls to raisewindow(). It's the only place I see gdk_window_raise() called. For the backdrop, gdk_window_lower() is called (they both change the z-ordering of windows), but the two calls are similar in that they're only requests to the window manager, and not guarantees.

Well, no luck so far. I did look for raiseWindow calls but found nothing helpful - and I'm probably hoping to find the place where raiseWindow should have been called but wasn't (why doesn't grep have an option for that? )

I tried to find the code that generated the dialog boxes, and I expected to be able to find the string "save changes" somewhere, since that's part of the message in the first dialog box. But it doesn't appear anywhere in the C++ code. Perhaps the message exists as a resource in an i19n database?

So now I'm wondering whether the dialogs are generated by the IDE's stacks and I need to start searching them. But that's where my lack of familiarity with LiveCode fails me: I've so far failed to find those stacks.

I'll keep looking - be grateful for any insights though!

The text "Do you want to save changes" is in Toolset/libraries/revbackscriptlibrary.livecodescript, so it's at the LC script level, not deep in the C++ engine code.

Thanks for that - it got me looking in the right place at last!

No joy yet though. Each dialog box from my original recipe is put up by "answer ... as sheet" and there's nothing different that I can see, so I guess there must be something about the sequence of events before the calls. I'll try to find some more time for it but it's unlikely to be in the next few days.