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 (the s...

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 Jacque sug...

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 rep...

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,revUpdateScriptEd...

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 that if I ...

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 of ...

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 between ...

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 th...

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 unique w...

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 ret...

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 and ...

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 other ...

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 want to...