LiveCode Forums.

Hi All,
Here is a little example: Now my question is how do I get that to only beep once?
I can't add any checks before the beep (like "if x = 4 then beep").

I had thought that that if/then would send it back to the top but it actually stores how many times mouseUp was called.
To help, think of it the way I did and see if you have a solution.
Something cool like "clear mouseUps".

Thanks,
Simon

Simon, Using your code base, try this: The declaration of the "local" x outside the handler makes the value in x persistent for the session. After the first run through of your code x gets very large and the recursion limit (400000 on my system) hits.

The "exit mouseUp" avoids the recursion, and the "put 0 into x" resets the persistent local variable.

Walt

Hi Walt,
Sorry if I described the problem incorrectly.
The point of the example is to actually repeat mouseUp but not the beeps.
Any thoughts?

Thanks,
Simon

Rats!
Is it really; Simon

Simon.

I have run across this before, where portions of a handler seem, as you say, to be queued somewhere, to be released all at once. I only use soft breakpoints, and I think these are what I remember, and are queued as well.

Certainly the second handler you wrote is the simplest and most straightforward. It is what I would have written from the start.

But your point, that calling "mouseUp" from a certain place in a handler ought not to "load" those downstream breakpoint commands,, seems valid. Why are they somehow "seen", just because the message itself is called again and again. Bug or feature?

Craig

I'm not getting what you are trying to achieve with this.

Given the latest, what's with the repeat loop? It has the same effect asdunnit? If you need more of the loop flavour calling mouseUp iteratively like the first version wouldn't it be something like erm. Still unclear what you're investigating

Sparkout.

Try Simon's first handler. Step through it to the end. The breakpoint is reached after four "mouseup" calls, and then the portion after the breakpoint runs four times as well.

Simon's point is that the portion below the "mouseUp" call should not be applied, should even be visible, during the operation of the handler itself. I agree. Of course, I could be wrong about that "not be applied" thing. During compilation, it obviously is.

Bug or feature?

Craig

dunbarx wrote: But your point, that calling "mouseUp" from a certain place in a handler ought not to "load" those downstream breakpoint commnads,, seems valid. Why are they somehow "seen", just because the message itself is called again and again

The example is recursive. Every time it's called the next iteration is nested inside the previous one. When each iteration completes, the calling one continues where it left off, so as they unwind you hear all the beeps and any breakpoints trigger (but in reverse order.)

..........

Thanks Everyone,
This one just caught me by surprise as I didn't think liveCode worked that way. I had use something similar before and it worked well but now I see that in that case the if/then was the last line of the handler.

Sorry to those machines I put through one of those "recursive limits reached" things.

Simon

Simon,
let me add this note to the code example of your starting post:

What *essentially* causes the infinite loop is TMHO not the missing "exit mouseUp" but is the check "if x <> 4" instead of "if x < 4".

Hermann

Hi Hermann,
Yeah, I got that, was just very poor coding style on my part. Wasn't essential to the question.

Thanks again,
Simon

Jacque,

I figured it had to be something like that. But like Simon, I just didn't think LC worked that way. I was thinking very linearly, I guess. Very stepwise.

I still do not quite see the nesting you speak of. Rather, like a line of code that "sends" a message to another handler, (where I do believe there is a true branch out of the calling handler), I thought of the structure of Simon's first script similarly, that the recall to "mouseUp" branched out of itself, and did not nest itself, er, within itself.

Brain tired. Go sleep now. zzzz

Craig

Hi Craig,
Thanks for getting my poorly written post.
Here is a better example; For those of you who are just joining in, before you try that code, how many beeps do you think you'll hear?
No, I'm not arguing that it should be different, just a surprise.

Simon

dunbarx wrote:I still do not quite see the nesting you speak of. Rather, like a line of code that "sends" a message to another handler, (where I do believe there is a true branch out of the calling handler), I thought of the structure of Simon's first script similarly, that the recall to "mouseUp" branched out of itself, and did not nest itself, er, within itself.

We may be talking about the same thing, but I see it more like nesting. If you substitute a different handler name for the nested "mouseup" it might be more clear. When a mouseup calls another handler, the second handler executes and then control returns to the mouseup, which then finishes. The same thing happens here -- only the "second" handler is a call to itself.

When that happens, each self-call "nests" inside the original. The remainder of the previous mouseup(s) are suspended while the "inside" ones finish. As each completes, the one that called it will resume execution and complete, and then the one that called that one completes, etc all the way up to the first one which the click originally triggered.

I think my explanation may be more complicated than the actual flow. Let's see if I can make a diagram...
This one only has 3 calls but maybe it shows the idea anyway.