A possible race condition

[drhoward]

I have a program that uses long running loops. Within these loops, I''m copying one buffer into another, byte by byte. There are times that I may need to abort the operation so I created an "Abort Button". Within these loops I also have a test so that every 1000th time through the loop the program updated a progress bar. Right after updating the progress bar, I'm checking on whether the abort button has been pushed. If it has, then the index on the loop is modified to terminate the loop.

I'm running into a problem in that clicking on the abort button is not registering while the loop is running. In other words, it appears that the interrupt from the mouse click isn't triggered. I tested this by putting an "answer message" into the mouseUp handler for the abort button. It doesn't appear to get triggered while the program is in one of the loops (there are three of them). This appears to be a race condition (a problem with system priority).

I'm using LiveCode version 7.0.3 under a Windows 7 operating system.)

Please advise!

[SparkOut]

Within the loop put a statement

Code: Select all

wait 0 milliseconds with messages

this will give the engine a moment of as near to no duration as can be, but in which it can catch up with some housekeeping tasks like keyboard polling, screen redrawing and handling mouse clicks.

[dunbarx]

How are you checking to see if the button has been clicked on?

Code: Select all

if the mouse is down and the mouseLoc is within the rect of btn "abort"

That sort of thing? You might try something more robust, just to see if it works:

Code: Select all

if the optionKey is down

If that works, you might have a clue as to whether the other method is hanging somehow, or being neglected.

Craig Newman

[drhoward]

The "wait 0 milliseconds" worked fine. I turned off the visible property within the mouseUp handler. With the wait command, installed in key routines, the abort button disappears when pushed and the program aborts properly.

Thanks!