Modal dialog that can't be dismissed?

[PlaidFlannel]

During development work, at significant milestones, I close my stack, duplicate the stack file, rename it with an incremented version number, and then open that new stack. However, as a LiveCode beginner, I'm apparently omitting a step, because this process results in a dialog like this:

The problem is that none of the buttons in this modal dialog do anything. My only recourse is to use the MacOS "Force Quit..." menu item to completely abort LiveCode.

Is this a known problem? Is there a workaround?

[richmond62]

Well, what I do know is that if you rename a stack "STAK1" to "STAK2" unless you do
a 'save as' all that effectively does is change the name of "STAK1" to "STAK2", but will
save what you have named "STAK2" into the file "STAK1".

I close my stack, duplicate the stack file, rename it with an incremented version number

That is not going to do you any favours at all.

Mainly because you are duplicating your stack file using the operating system, so preserving its internal name ["STAK1"].

Try this:

1. With your original stack open [I shall call it "STAK1"] rename the thing "STAK2".

2. Perform a save as, and that should save your stack with the name "STAK2".

[stam]

The problem is that none of the buttons in this modal dialog do anything. My only recourse is to use the MacOS "Force Quit..." menu item to completely abort LiveCode.

Have you upgraded to Big Sur?
If so, have you updated LiveCode to 9.6.2 RC1 or greater?

They fixed a number of glitches with Big Sur, including what you’re describing if I’ve understood your problem correctly... (non functional buttons on modal dialogs).

HTH
Stam

———————————
EDIT: download the latest and greatest from https://downloads.livecode.com/livecode/

[dunbarx]

To say it another way, renaming the stack is NOT the same as renaming the stack file. They are two entirely different things, and act on two entirely different "objects".

I deal with the same issue, and always simply select the "purge" option. But are you saying that it is impossible to dismiss the dialog? That would be something of concern.

Craig

[stam]

I had this issue when i upgraded to Big Sur

The LC team / Panos fixed this and other issues in the release candidates for 9.6.2. I'm using 9.6.2 RC2 and no longer have this issue.

I suspect that's the problem the OP has... but hopefully they can confirm.

[jacque]

To avoid the same problem of seeing the warning dialog, even before Big Sur, I always do this:

• Duplicate the stack in the OS (Finder on Mac, Explorer on Windows. )

• Change the file name of the duplicate.

• Continue working on the original copy.

[PlaidFlannel]

Thanks to all the responders.

I think one of my misunderstandings is the concept of "purge". Searching for that term in the Dictionary and the Tutorials produced no hits. But apparently, opening and closing a document (stack file) has some hidden behavior unlike that of most other applications.

The idea that closing a stack doesn't really close it would also explain why the Project Browser tool sometimes shows stacks other than the one I'm working on. And I might now guess that the menu item "Close and Remove From Memory" is a synonym for "purge".

The "Stack Inspector" suggests that "Name", "Title", and "Main Stack" are different entities, and all of those may be different from the stack file name. I'll have to give some thought to how to take advantage of all of those in improving my ad hoc version control procedure.

Still, it would seem that a modal dialog should have at least one button that works, even if it is just the "Cancel" button.

[PlaidFlannel]

While we're on the subject of dialogs that can't be dismissed, I also encountered this one:

I could not get it to respond to any mouse or keyboard inputs.

[jacque]

The idea that closing a stack doesn't really close it would also explain why the Project Browser tool sometimes shows stacks other than the one I'm working on. And I might now guess that the menu item "Close and Remove From Memory" is a synonym for "purge".

That's right. If you look at the stack property inspector you'll see two properties, "Destroy stack" and "Destroy Window". The latter is mostly for Linux, but destroyStack determines whether the stack is removed from memory when the close button is clicked. If unchecked, the stack is removed from the message path and hidden, but is still in RAM. If checked, it purges the stack compeletely. The default is not to destroy, so that's why you get the warning when it seems that you've already closed the stack.

There is a setting in LC preferences where you can set all newly created stacks to use destroyStack automatically. I keep that selected. The ability to retain a stack in memory while not actually using it dates back to slower CPUs and older machines. These days, with very fast processors, it usually doesn't take any noticeable time to open a stack so the property is a little dated now.

The "Stack Inspector" suggests that "Name", "Title", and "Main Stack" are different entities, and all of those may be different from the stack file name. I'll have to give some thought to how to take advantage of all of those in improving my ad hoc version control procedure.

The name of the stack is what scripts use when referring to it. The Title (or "Label") is what appears to the user in the titlebar of the window. If you don't supply a title, the stack name is used by default but you'll see an asterisk in the titlebar. I find it convenient when scripting to use a short stack name ("histLit") and a longer, more explanatory name for the user to see ("Historical Figures in Literature".)

The stack's filename is the one used by the operating system. The above might have a file name "Hist_Figures.livecode".

So we have three names, each with a purpose:
File name -- disk name
Stack name -- script reference
Title/Label -- Window title bar label

Mainstack: Every stack file (the file you see on disk) can have one main/primary stack and any number of substacks. Substacks are stacks that are attached to the main one, and can share the script of the main stack; that is, they are in the message path when open. They are handy when you need to create stacks for related purposes but you want them to remain attached to the same file on disk. I.e., in my Historical Figures example, I might want to use a substack to list a glossary of of people with links to the web. I could do this on a card in the mainstack, but that removes the user's attention from what they were reading. If I use a substack I can open it at the same time as the mainstack to be used as a lookup reference. Substacks are good for any number of things; they can be printing templates, custom dialogs, or tool palettes, can store resources, or do just about anything else that should appear or be stored in a second window. There is a dictionary entry for "mainstack".

[PlaidFlannel]

Thanks to jacque. That explains a lot.

[jacque]

I should add that substacks are always retained in memory until the mainstack is removed. LC opens the entire stackfile when the mainstack opens. Regardless of the destroystack property, substacks hang around.

[FourthWorld]

PlaidFlannel, which version of LC are you running?

[PlaidFlannel]

I'm running LiveCode Community 9.6.1.15522 on MacOS 11.1 Big Sur. (I almost always wait for a stable version.)

[stam]

As mentioned above, go to downloads.livecode.com/livecode/

Download 9.6.2 RC2 and your problems with non-clickable modal dialog buttons will go away...
I've been using it for months and it's at least as stable as 9.6.1...

If you really want to only download final versions, that's an issue you'll have to live with (i couldn't...)

Stam

[FourthWorld]

As mentioned above, go to downloads.livecode.com/livecode/

Download 9.6.2 RC2 and your problems with non-clickable modal dialog buttons will go away...
I've been using it for months and it's at least as stable as 9.6.1...

You've been very helpful. Maybe third time's a charm?

This is another good reason why doing daily development with the latest engine is so helpful, for everyone. The latest version has the latest bug fixes, and if you find an issue you'll want to test it in the latest version before submitting a report anyway.