LiveCode Forums.

I am writing an app on which the main stack has a RUN button. This activates code incorporating a timer loop which could run for several hours. I would like to incorporate an ABORT button on the stack which when pressed by the user, exits the loop, does some housekeeping, then closes the app.
The problem I have is that when running, all objects on the stack are "frozen" and inoperative. Is there a way to keep a button active, or at least visited periodically by the program? I am coding for an android mobile.

Hi.

This should be in the beginners forum. Klaus?

Anyway, there are several ways to do this. One way is to check the state of, say, whether the mouse is down or not periodically. PseudoCode"

on mouseUp
repeat a billion
do some stuff
if the mouse is down then exit to top --or maybe open a dialog?
doMore Stuff
end repeat

That sort of thing. Now make a new button, and think about this in its script. Experiment, read up on what you find interesting in the dictionary, and write back. I assume you will click on the button now and then, and the shiftKey if you really want to.

Craig Newman

Thanks, Craig

Your pseudocode above is what I hoped to do. It works fine on a windows pc, but when converted to android on a mobile device the buttons appear to be frozen, and there is no keyboard.
I have experimented, and find to my surprise that on the mobile although the buttons do not react (change color) when pressed, the script attached to them appears to run. I will do some more trials and let you know the results.
Although I have coded in other languages (euphoria is my favorite) I find LiveCode has a steep learning curve. But I am enjoying it.

Hi jaybeedee,

1. welcome to the forum!

2. How on earth do you think your question is OFF-TOPIC?
Will move this thread to the beginners section.

3. Would you please post your code/handlers?
We might need to take a look at it to be able to help you!


Best

Klaus

dunbarx wrote:One way is to check the state of, say, whether the mouse is down or not periodically. PseudoCode"

on mouseUp
repeat a billion
do some stuff
if the mouse is down then exit to top --or maybe open a dialog?
doMore Stuff
end repeat

I don't recommend this approach. It worked in HC but in LC it will only work reliably if the time required to execute the repeat loop is shorter than the time it takes to click the mouse. That's because LC only checks the mouse state when it executes that line in the repeat; it doesn't keep a history of mouse downs and ups like HC did. If the mouse has already been released when that line executes, the loop will not exit.

However, it is the way to do what the OP wants in general, because instead of checking the mouse state the script can check a script local variable to see whether to continue or not. But that requires that "wait" line from this handler:

That sort of thing. Now make a new button, and think about this in its script.

Code: Select all

on mouseUp
   put 0 into msg
   repeat until the shiftkey is down
      add 1 to msg
      wait 0 with messages
   end repeat
end mouseUp

This is a much better approach because it allows time for background processes to execute (which means you can click other objects among other things) and doesn't rely on the length of a click, which can vary by machine depending on the OS mouse settings.

Since there is no shiftkey to test in this situation, the OP will need to set a flag that determines whether the loop should continue or not. When we see the original script we can help with that.

Thanks Klaus and others,

I could not find any reference to "Abort" in any of the topics in the forum - hence "out of topic" Is that logical?
Anyway this post might be more appropriately placed in the Android development section as this is the platform I am coding for.

This is a simplified version of what I would like to do.
Create a new mainstack with buttons "Run" and "Abort" and a label "Label"

Define a variable getOut as global

Code button Run
global getOut
on mouseUp
put 0 into getOut
repeat with x = 1 to 50
if getOut > 0 then answer "Ended by user"
if getOut > 0 then exit mouseUp
put x into field "Label"
wait 1seconds
end repeat
end mouseUp

Code button Abort
global getOut
on mouseDown
put 1 into getOut
end mouseDown

After pressing Run the Abort button is frozen. I guess this is because you can't have two scripts running concurrently. Is there a way of passing control to the Abort button briefly in every cycle of the repeat loop?

The two examples given by Craig work fine, but require the presence of a mouse or keyboard so not suitable for a mobile. Also "mouse is down" command is not available on the Android platform.

I'm sure there must be some built-in procedures to cope with this situation, but I haven't found them yet.
Any suggestions?

Thanks in advance

Hi jaybeedee,

try this: Best

Klaus

What Jacque and Klaus said.

And me.

You needed to actually do what I asked, to

...read up on what you find interesting in the dictionary, and write back.

Maybe that was a bit indirect. I wanted you to find what the "with messages" meant, and how it was essential for certain tasks.

Right now, "wait" is blocking, and the only way to release control is to add the "with messages" variant. This issue may be addressed in LC 7.

Craig

Thanks Craig, Klaus and Jacque.

Wait with messages works perfectly. Somehow I had assumed that the "with messages" bit referred to text messages as in a msg box, NOT system messages. Now that's sorted, the Abort button is a doddle!

Just as a technical detail. Am I right in believing that the wait command takes a load off the processor thereby saving battery life on portables, while with wait with messages the processor will be active waiting for some action?

Thanks everyone for your very quick and helpful replies. LiveCode has such a huge vocabulary its difficult to find what you want.

So here is something to think about. Mac OS 10.9, LC 6.6.2, In a button somewhere:

Run this handler. Using the activity monitor, while the msg box is happily being updated (optionKey down), about 9% of the CPU is being used. While the handler is waiting (optionKey up) CPU usage rises to about 23%. Apparently, like watching too much TV, waiting is not good for you. Not sure how this translates to mobil.


Craig