LiveCode Forums.

Of course, I could use the dialogData to test the clicked button but I thought that the "exit to top" command stopped all scripts.


There are several workarounds (I still believe that using the dialogData global property is the simplest).
"Exit" button script:
on mouseUp
set the dialogData to ...

No need to apologize Jacque, you can do whatever you want (on this forum) :D
I just tried "start using..." but it doesn't change anything.

It looks like a bug : in my opinion, exit to top command should really stop all scripts.



So, the problem lies with using a modal stack.

I think so. As ...

Sorry to interrupt this ethno-idiomatic discussion
Here is a test stack that shows that the substack exit command does not stop the modal dialog calling script.

@richmond62: the substack's destroyStack is already set to true, but that's not the problem. The problem is that the "exit to top" command should stop *all* running scripts. As far as I know, all programming languages ​​have an exit or die command.

@stam: the global dialogData property is a good ...

Thank you for your answers Stam.

For pending messages, I wouldn't really know which one(s) to delete:
6003,1724478869.547847,ideMessageSendWithParameters,stack "/Applications/LiveCode 9.6.13.app/Contents/Tools/Toolset/libraries/revidelibrary.8.livecodescript"
6004,1724478869.558268 ...

Hello,

I have a substack that serves as a modal dialog . I call it with script like:
modal stack "mySubstack"
put " Dialog closed!" after msg
This substack displays an "Exit" button whose script is:
on mouseUp
close this stack
put "Closing dialog..."
exit to top
end mouseUp
The problem is ...

otherwise I personally would default to readable/maintainable code rather than treat everything as speed race - but that's just me ;)


I agree.
(even when splitting the code into multiple subroutines, I often have trouble rereading old code... but that's another topic: it's the problem of a lack ...

II am a bit obsessed with speed and that is one of the reasons I put my code into one long handler. (within reason). Branching into subroutines is probably better coding practice but is a tad slower.


I noticed that using subroutines significantly increased execution time. We have to choose ...

I just tested your stack, Bernd : it is very very fast (and probably accurate of course).

I haven't tested yours, Stam , but, from a user's point of view, I think it could be handy to have an option (a parameter) to restrict the search to the scripts of all controls in the initial mainStack - and ...

stam wrote: Tue Aug 13, 2024 8:44 am But here is where revRuggedID() is probably better. As the ID is only guaranteed to be unique within a single stack, you cannot key an array to the ID in more than one stack - eg substacks - and maintain unique identifiers.

Right.

I only just noticed this but at first glance it loos like subStacks don't have a separate ID?
Seems to be 1002 for all subStacks, the same as any new stack -- is this right?


Very interesting point!

I just reread the Dictionary and, when it says " For all objects, the ID is guaranteed to be ...

You could use the "ruggedID". The IDE has a function that returns the ruggedID

Interesting! I had noticed the use of ruggedID() in your scripts but I had not looked in detail at what this function did.
Thanks Bernd :)

I'll do some more testing but it seems to me that sometimes the backgroundIDs ...

With all your ideas and different tests, here is what I finally did. It is not necessarily the fastest solution - and the script can probably be optimized - but it meets my different needs.

function getStackControlList pStackName
/*
return a tab-cr delimited list of all controls of passed stack ...

You can turn off field text in the "Find..." menuItem.


Yes, I had noticed the different options of the Find Dialog but:
1 - as far as I know, no options allow to display the number of found occurrences
2 - my idea is to be able to recycle the function that lists all the controls to use it in ...

But I'm still wondering, and forgive me if this was addressed earlier: what isn't working in the IDE's tool built for this purpose?


For several reasons.
In my LC 9.x Indy, the UI doesn't return the number of found occurences.
The built-in "Find" UI is too complicated for my needs : I always ...