LiveCode Forums.

exheusden wrote:Firstly, note that a stack window is already open, together with the Tools Palette, when a substack is opened with "go", causing the Tool Palette to disappear.

Then,

FourthWorld wrote:So using "go" seems to fix the problem…

No, using "open stack" seems to fix the problem.

Thanks for catching that. Obviously I meant "open", and have correct my post.

You also write that using "go" effectively causes the tool window to be replaced. Well, in a way, though the newly opened window does not occupy the same place as the disappearing Tool Palette.

Nor would we expect it to, since the windows are of different size. If you want to use "go...in window..." and preserve the rect of the original window, you'd first want to set the rect of the destination stack to match that of the original.

I don't know if it has anything to do with this, but closing a window with the red close button always causes the "Do you want to save changes to stack…" message, even when no changes have been made (indeed, even when nothing at all has been done with the stack, other than oening it). I've tried this with reasonably complex stackes (stacks with many cards and with substacks) and also with simple one-card stacks: I *think* this always happens with LiveCode.

Do you also see that when closing the Tools stack?

Hi exheusden,

always causes the "Do you want to save changes to stack…"

I get this if my stack does any ssl decoding, while no changes are done it still thinks I changed something.
Might not have anything to do with your stack, just throwing it out.

Simon

FourthWorld wrote:Do you also see that when closing the Tools stack?

No!

Thanks. Not sure how to proceed, since I've been unable to reproduce this. Has anyone else found a consistent recipe to reproduce this?

I've never seen it either but there have been reports from a couple of others who have, so it does happen.

The "do you want to save" business has been an irritation for me ever since the first version of LiveCode was released. I haven't done an extensive test but long experience with it seems to indicate that a stack is marked as "dirty" whenever an openfield happens (among other things,) regardless of whether any text is typed. This is linked to the (in my view, unfortunate) behavior of the engine automatically selecting the text of the first editable field whenever a stack comes into focus. The automatic text selection triggers an openField message and the stack becomes dirty, even if you haven't done a thing to it. The tool palette doesn't do that because it doesn't have any editable fields.

I find it quicker to type "close this stack" into the message box than to deal with the confirmation dialog. Now that we have auto-complete in the message box, I rarely have to type the whole phrase anyway.

Back to the tool palette disappearing: since I've never seen it I don't know why it happens, but if you can repro it every time then it's worth reporting to the bug database. The occurance is rare (I think I only remember two other people who saw it) but it's likely a bug in the IDE. But first be sure that you don't have any repeat loops in your scripts that close all open stacks.

Things get more complicated.

Today, even the script

on mouseUp
open stack "eBook templates"
end mouseUp

causes the tool palette to disappear (whereas, curiouser and curiouser, a go to stack no longer does!)

There is some truth in your idea that a stack might be marked as "dirty". I have just made a very simple stack and substack to test this and, indeed, every time I open the substack from the main stack and then try to close the substack, without having done anything at all, I get the save message. However, I don't think it is necessary to always place a cursor in a filed: I have substacks that have editable fields, but none is actually selected when the go is performed, yet I always get the save message. So merely having editable content seems to be sufficient.

Could all these problems have anything to do with the fact that all of my stacks, with the exception of the test stack I made today, are very old? Many were started in the days of HyperCard and passed through SuperCard, to go through mods in RunRev and are now being accessed by LiveCode.

I don't think the age or number of apps your stack has been through is the problem. When you import a stack into LiveCode it basically rebuilds it from scratch. But there could be something in one of your scripts that closes all windows, and if it doesn't account for the IDE stacks then that would cause the tool palette to disappear. On the other hand, the IDE goes to some lengths to avoid that so I'm not sure. Or maybe there is some other incompatibility in a script somewhere.

Use LiveCode's "find and replace" menu item to search for all instances of the word "close" in all scripts. See if that shows anything that might be suspect.

If that doesn't suggest anything, set a breakpoint in a script somewhere before the tool palette problem occurs. That could be in a closecard handler, or a preOpenCard/preOpenStack or openCard/openStack handler somewhere. When the debugger appears, step through the code one line at a time until you find the point where the palette goes away. That might help determine where the trigger is.

If none of that helps, let us know and we can take it from there.

I shall do as you suggest, but first this.

I wanted to record in a movie what was happening in case anyone couldn't envisage it or just didn't believe it

With the Tools Palette and my main stack visible, I started QuickTime Player, which has an excellent tool for partial screen capture in video format. As soon as I clicked outside LiveCode (in this case, in Finder), the Tools Palette disappeared, whereas my main stack remained visible (and, just in case, I used Mission Control to check that the Tool Palette had been removed and not merely placed somewhere it could not be seen). Anyway, clicking in the main stack brought the Tools Palette (and the Message window, incidentally) back again and you can see how it automagically disappears in a small movie (1.5 MB) at http://davidneale.eu/movies/ToolsPalette.m4v

What you see is LiveCode with apparently just one window active, that of my own stack; I click in this to activate the two other windows that were active prior to starting QuickTime Player, namely the Tools Palette and the message window. I then click the ePub templates button: this causes the Tools Palette to disappear and a card of the substack to appear. I close the substack window by clicking its standard OS X window close button. This produces the "Do you want to save" message, which I dismiss and the window closes. I go to the message window to execute the "set the visible of stack "revTools" to true" command and the Tools Palette reappears.

Here, the script of the ePub templates button was

on mouseUp
open stack "eBook templates"
end mouseUp

Changing the "open" to "go" produces the same result.

It's normal behavior for apps to hide their palettes when they go into the background. Toplevel stacks stay visible; in other apps, the main document window stays visible. So that part is expected.

It looks like your templates stack is a palette. What happens if you make it a toplevel stack, just as a test?

I can't see it in the video but do you have "Hide Pallets" selected in your Preferences under Script Editor?

Simon

Simon, you're question has solved it (I think).

I checked all the Close commands, as earlier suggested, but these refer only to local files that are read or created. Thanks to your suggestion, I looked for "hide" and I found a "hide stack "revTools"" in the openStack script of the main stack. Commenting this out seems to prevent the hiding of the tools palette when moving from the main stack to a substack (even though there is no such openStack script in any of the substacks).

Cool. I figured it had to be something like that.

Substacks inherit the stack script of the main stack if they don't have their own handlers. If your substack has no openStack handler, it will use the one in the mainstack. That's why it triggered.

Glad you were able to find it.