How to interrupt a recurring message? (SOLVED)

[MaxV]

Hello,
I'm trying to interrupt a recurring message, but it stops many times after I click the stop button.
The stop button set a property (avvio) to false.
The problem is:

• the stop button seems unclickable, but it's clickable
• the result of stop button happen many times after the click, i.e. the messages is stopped many time after I click the button
• I can't use send message to me in xx sec, because I don't want to loose time.

Here my code of the reccurring message (CercaFiles):

########CODE#######
on mouseUp
set the avvio of me to true
cercafiles (field "startingFolder")
end mouseUp

on CercaFiles curFolder
set the defaultFolder to curFolder
put the files into temp
put the text of field "nomeFile" into nomeFile
repeat for each line tLine in temp
if the avvio of me is false then exit to top #here check to stop the recurring message
if matchText(item 1 of tLine, nomeFile ) then
put Curfolder & "/"& item 1 of tLine & return after field "listaFiles"
end if
end repeat
put the folders into temp2
repeat for each line tLine2 in temp2
if tLine2 is not "." and tLine2 is not ".." then
cercaFiles(curFolder & "/" & tLine2)
end if
end repeat
end CercaFiles
#####END OF CODE#####

[dunbarx]

Hi.

If you require that "the avivo of me" be false in order to exit, then that property must be set to false now and then. i do not see it.

Craig Newman

[MaxV]

I have another button that set that property to false.
If I try to press that button, the button seems frozen; however the MouseUp is sent and is activated after 30 seconds or more that I clicked...

[MaxV]

This video show the problem, I click immediately the stop button and it doesn't seem clicked, but the program is stopped 40 seconds later: https://www.youtube.com/watch?v=XxX4aNnoUr8

[mwieder]

Your repeat loops are not allowing other messages to be handled. Inside your repeat loops insert the line

Code: Select all

wait 0 with messages

This line that seems to do nothing (wait for 0 seconds) will allow the system time to process messages from other objects... otherwise they just get queued until there is some idle time.

[dunbarx]

I hear that this issue, waiting for 0 with messages, is going to go away in v8. Is this so? How does a loop release the CPU while it has control?

Craig

[mwieder]

Is this so?

Nope. That would break existing stacks.

[dunbarx]

Mark.

Richard Gaskin wrote:

As for "wait 0 with messages", that was a workaround needed on OS X in earlier versions of LiveCode to accommodate an anomaly in the Mac redraw subsystem; it should never have been needed on any other platform, and with recent LiveCode builds should not be needed at all.

That this might not be needed in the future would not break legacy code.

Perhaps I am misunderstanding?

Craig

[mwieder]

Since I don't have any context for that sentence, I should probably let Richard respond himself.

My guess, though, is that he's referring to osx display anomalies, where the same sort of yielding to system tasks has been necessary and is no longer required due to improvements in the core graphics functionality in the engine.

That, however, has no bearing on the use of 'wait 0 with messages' in other contexts in order to yield time for queued messages.

[dunbarx]

Mark.

Makes sense. The statement was too "blanket". Or my interpretation was.

I know loops will not give up their control lightly.

Craig

[FourthWorld]

My understanding is that the fix for the older Mac-specific need to explicitly free up clock cycles for redraws was fixed with the Cocoa changes, now part of v6.7 and later.

There's no new penalty for adding the "wait 0 with messages" workaround; it still does what it used to do in granting additional time for the OS event loop. It's just no longer needed for redraws, so now the Mac engine works on par with Windows and Linux.

[dunbarx]

Richard.

The statement was too "blanket". Or my interpretation was.

Yep, my interpretation.

Craig

[mwieder]

No worries, Craig. I didn't know about the Cocoa improvements until you brought this up, so thanks for that.

[SparkOut]

My understanding is that the fix for the older Mac-specific need to explicitly free up clock cycles for redraws was fixed with the Cocoa changes, now part of v6.7 and later.

There's no new penalty for adding the "wait 0 with messages" workaround; it still does what it used to do in granting additional time for the OS event loop. It's just no longer needed for redraws, so now the Mac engine works on par with Windows and Linux.

Windows has always needed and still does (up to 7.1.1 - not tested with 8 ) require a wait with messages inside a tight repeat loop. It's not explicitly for old Macs.

[MaxV]

The code:

Code: Select all

wait 0 with messages

resolved all.
Thank you guys!