Need suggestion for using a modal dialog

[rumplestiltskin]

I have a stack that queries the user for some info, checks it for proper formatting, and then puts that info into a field. Everything is working fine and, at the end of that script, it calls a script in the stack to do a calculation and set some button icons. No problems.

However, as the user of this stack (my wife) has requested some enhancements, I decided the user interface was getting somewhat unwieldy with all the buttons that had to be disabled, enabled, and renamed in order to prevent errant clicks while an operation was taking place and needed to be completed before any other operation was started. In other words: I was "faking" a modal dialog by messing about with many other UI elements. That's bad scripting on my part.

I'm cleaning it all up now but found an issue with referencing objects that appears strange to me (not the objects but the referencing). This arose only when I started using the "sheet stack" command. [Edit: I deleted "modal" and substituted "sheet".] My scripts referencing objects in the main stack now require that I identify the stack. As an example, I used to write:

Code: Select all

put theVar into line x of field y

but, now, using this script in the substack (the modal dialog), I have to write:

Code: Select all

put theVar into line x of field y of stack mainStackName

What's even stranger is that the script in the substack, after closing the substack (but before finishing the script) calls that script in the main stack. Again, what used to work:

Code: Select all

set the icon of button "sortListbyAmount" to 0

...now requires this:

Code: Select all

set the icon of button "sortListbyAmount" of stack "mainStackName" to 0

...even though the substack is closed and we're back seeing only the main stack.

So three questions:

1. Does the fact that the substack is closed have no relevance as we're still executing code that's being called from that substack? (It appears that way from the observed behavior.)

2. Am I in error thinking there's a one line command I may use to eliminate the need for the complete object reference (ie, including the stack name in each line of code that refers to an object in that main stack)?

3. Or should I re-write my code so that when the modal substack is closed, I just pass the variable to the next line in the button that opened the substack in the first place? I'm thinking:

Code: Select all

on mouseUp
	global myVar -- gets filled in the modal stack called in next line
	modal stack "myDialog"
	-- now myVar is filled in the modal stack
	put myVar into line x of field y -- do I no longer need "of stack mainStackName"??
	theTotal -- script in stack mainStackName
end mouseUp

Or is some sort of special command (see #2, above) the way to go? (I don't know what that special command might be.)

As always, suggestions are welcome and appreciated.

Barry

[bogs]

2. Am I in error thinking there's a one line command I may use to eliminate the need for the complete object reference (ie, including the stack name in each line of code that refers to an object in that main stack)?

Um. This is not a direct answer, but a variation on it. You could set the id of objectX into a custom prop in the main stack, then put that prop into the code call. So for instance, in the mainStack of the program you might do something like -

Code: Select all

set cp(shortNameOfObject) of stack "thisStack" to the long id of (the object)

Then in your sheet routine you would simply call that property instead of [button "sortListbyAmount" of stack "mainStackName" to 0], it would be [button "cp(shortNameOfObject)" to 0] if you see what I mean.

3. Or should I re-write my code so that when the modal substack is closed, I just pass the variable to the next line in the button that opened the substack in the first place? I'm thinking:

Well, that is how I would go as the writer. I've found that no matter how messy the code I started out with was, in the long run re-writing it is often better than trying to keep it alive since I am also the one (here anyway) that has to maintain it.

Take that with a grain of salt, though, I'm not exactly conventional

[dunbarx]

Hi.

I am not sure how pertinent this is, but know that even upon closing a substack (or any stack at all), it is still alive and in the message hierarchy. This even if the "destroyStack" and "destroyWindow" properties are set.


Craig Newman

[jacque]

Am I in error thinking there's a one line command I may use to eliminate the need for the complete object reference

You're right, you can use any one of these:

set the defaultstack to the topstack
set the defaultstack to the owner of me
set the defaultstack to "myMainstackName"

Technically when you "go" to another stack, it will become the defaultstack when it opens. In this case the mainstack never closed so the defaultstack doesn't change and remains set to the modal.

[FourthWorld]

Craig, my understanding is that stack files are loaded or purged as a whole. As long as any stack in a given file is open, all parts of the stack file remain in memory.

Those that also remain in the message path should be limited to the ones explicitly bought into the path as frontScripts, libraries, or backScripts. Any exception in which a closed stack remains in the message path would seem a bug worth reporting

[rumplestiltskin]

Many thanks for the explanations, clarifications, and advice.

As I do not code on a daily basis, I try to look for the most straightforward approaches that will make sense to me when I return to the project six months from now. What I've done (based upon your posts) is this:

1. In the mainstack, when the user clicks the appropriate button, populate some global variables with necessary information from the main stack.
2. Call the modal (sheet) substack.
3. Take the information from the global variables and let the user do what needs to be done in that model substack.
4. Populate the global variables with the altered information when the user accepts the result.
5. Close the modal substack.
6. Back in the main stack, process the info from the global variables to do the rest of what needs to be done. (In some cases, the script here (in the button in the main stack) also calls a script in the main stack.)

It appears that I no longer need to use "of stack myMainStack" in any of the references as long as I don't try to refer to an object in another stack. Of course, now it all makes sense. The errors were complaining about a non-existent object (that actually did exist!) and adding the "of stack myMainStack" resolved things. But I felt that having to add this reference was a band-aid that needed to be ripped off, if you'll forgive my metaphor.

From Texas, thanks y'all for your help.

Barry

[dunbarx]

Richard.

Those that also remain in the message path should be limited to the ones explicitly bought into the path as frontScripts, libraries, or backScripts. Any exception in which a closed stack remains in the message path would seem a bug worth reporting

To be sure we are talking about the same thing. If I create and save a stack "XYZ", and put this in its stack script:

Code: Select all

on xxx
  answer random(999)
end xxx

I again save the stack and close it. The destroyStack and destroyWindow are all set to "true". This stack ("XYZ") is the only stack in its stack file. No scripts have been sent forward or backward.

From msg, I then:

Code: Select all

send "xxx" to stack "XYZ"

I get an answer dialog with a number.

Do you see this as expected behavior? If not, we should open a new thread.

Craig

[FourthWorld]

IIRC "send" does not require that a stack be in memory; if it isn't, it will be loaded so the send can be fulfilled.

[rumplestiltskin]

{snip}...Technically when you "go" to another stack, it will become the defaultstack when it opens. In this case the mainstack never closed so the defaultstack doesn't change and remains set to the modal.

This explains why passing information contained in fields in both stacks using only variables and, in the handlers, not referring to any fields in other than the current stack (or substack) is working for me now. Once you (I, actually) know this, the scripting is straightforward.

I was also able to consolidate three tasks (Add, Duplicate, and Change a "record") in that one substack using labels whose text I changed dynamically depending on the task and some "if/then" statements in the one "OK" button in the modal substack. I had originally thought I would need three substacks. The next step is printing but I'll create a new thread for that rather then hijacking my own.

Thanks

[dunbarx]

IIRC "send" does not require that a stack be in memory; if it isn't, it will be loaded so the send can be fulfilled.

Nope. The stack has to be in memory.

Interestingly, with the scenario I described above, upon closing, the stack no longer receives messages. This flies in the face of the comment I made above and also a thread I opened a short while back about being unable to purge stacks upon closing them.

Need more testing. The dictionary implies a stack has to be in memory to receive messages. See "send".

This is a much simpler stack, in the example above, so maybe there is more going on with my much larger project. Anyway, you cannot send a message to an unopened stack. And how would LC know, unless it searched the entire hard drive for a stack of that name, and then opened it? The ask and answer file dialogs require explicit pathnames, whether navigated to or supplied.

Craig

[FourthWorld]

Many thanks for the explanations, clarifications, and advice.

As I do not code on a daily basis, I try to look for the most straightforward approaches that will make sense to me when I return to the project six months from now. What I've done (based upon your posts) is this:

1. In the mainstack, when the user clicks the appropriate button, populate some global variables with necessary information from the main stack.
2. Call the modal (sheet) substack.
3. Take the information from the global variables and let the user do what needs to be done in that model substack.
...

FWIW a global var is provided just for that purpose: see the dialogData in the Dictionary.

[FourthWorld]

IIRC "send" does not require that a stack be in memory; if it isn't, it will be loaded so the send can be fulfilled.

Nope. The stack has to be in memory.

I just ran this test:
1. Made a new stack, named "foo", with this handler in the stack script:

Code: Select all

on foo
  answer "Got foo!"
end foo

2. Saved it to my desktop.
3. Quit LC to avoid any possibility of the stack remaining in memory.
4. Re-launched LC
5. Created a new stack with a button containing this script:

Code: Select all

on mouseUp
   put specialFolderPath("desktop")&"/foo.livecode" into tStack
   send "foo" to stack tStack
end mouseUp

6. Clicked the button

RESULT: an answer dialog appeared with the words "Got foo!"

Seems to also work from a cold boot if I use "dispatch" instead of "send".

If you can produce a different result with that recipe we should note the version and file a bug report. My test was done with the version about to become the base standard, v9 RC1.