MouseStack not working?

[dunbarx]

I have two handlers in a button, and there are a few stack windows hanging around:

Code: Select all

on mouseUp
   doThis
end mouseUp

on doThis
   if the optionkey is down then exit to top
   put the mousestack && the mouseLoc
   send "doThis" to me in 5
end doThis

Works fine, and all other mouseFunctions (mouseChunk, mouseWhatever) do as well. But for this:

Code: Select all

on mouseUp
   repeat until the optionKey is down
      put the mouseStack && the mouseLoc
   end repeat
end mouseUp

The mouseLoc tracks just fine, but the no other mouseFunction does. Doesn't seem too hard to figure out, but I can't. Is it because there is no "repeat with messages"?

Craig Newman

[shaosean]

If you want other events/messages to fire during a repeat loop, use the "with messages" form..

[dunbarx]

Hi.

If you want other events/messages to fire during a repeat loop, use the "with messages" form..

I was sort of joking when I wrote

...is iit because there is no "repeat with messages"?

Such a construction will not throw an error, but it also has no effect on the control structure. It is not indicated in the dictionary, and no pendingMessages are queued.

My point was: why does the mouseLoc fire, but no other mouseFunction?

I am starting to use those emoticons like Klaus.

Craig

[SparkOut]

Try

Code: Select all

on mouseUp
   repeat until the optionKey is down
      put the mouseStack && the mouseLoc
      wait 5 with messages
   end repeat
end mouseUp

This gives you a "with messages" effect inside the repeat loop, and the same interval as the send in time method. Works as you describe without the wait 5 "with messages" but tracks the mouseStack like the send in time version with the wait with messages line included.

The answer to the question why does the mouseLoc track but not the other mouseMessages, when in the repeat loop without the wait with messages... I have no idea. But I know that unblocking a repeat loop with the with messages form of wait, to give the engine a bit of housekeeping time is one trick I use very frequently.

[dunbarx]

Sparkout.

A very clever idea. Add a line of code to force what I thought was a non-blocking process to work the way I thought it ought to all by itself. I like it.

But I am going to submit to QCC as a bug. If for nothing else than to be told it is not a big deal, or I am misunderstanding something.

Craig

[SparkOut]

Mmm. I don't know about clever, I have had this idea beaten into my brain ever since I started with LiveCode (Rev 2.7).
Of course a repeat loop is still blocking even if the engine is allowed to handle messages, send in time is more suitable if you want to have modules running independently.

There is a thread somewhere that suggests this approach is a workaround to an issue affecting Mac OS X but was resolved in an earlier version. That surprised me, as it has always been the same in every version I have used on windows.

Edit: http://forums.livecode.com/viewtopic.ph ... es#p109006

I'm not sure the Mac bug fix referred to is addressing quite the same thing. Bug 13142 referred to later is more like it.

[dunbarx]

Hi.

I really misSpoke. I know repeat loops are "blocking", because they run in-line. As opposed to "wait" (without messages), which puts the whole world to sleep.

But the properties I mentioned are requested in an explicit line of code, in line, and only the mouseLoc comes back. The line is not fully resolved and executed. That is why I consider it a bug.

Craig

[SparkOut]

No, I agree, no misspeaking involved. (Of course [and you know that]... etc etc rhetorical blah)

[dunbarx]

Mark W. replied:

Hi Craig,

Thanks for the report.

The only mouse function which is asynchronous is 'the mouseLoc' this returns
the position of the mouse at the time it is evaluated. The rest of the mouse
related functions all tie their result to the last dispatched mouse event - so
in the above case they will correspond to the position of the mouseUp.

I wouldn't say this is a bug as if it did not work like this then you would not
be able to capture mouse information reliably corresponding to the position of
the mouse event.

On the other hand, it does highlight a missing feature - the ability to get the
mouse position which is related to the current mouse event. Indeed, one could
argue that you should be able to do 'the mouse*' (related to position of mouse
event); and 'the current mouse*' (using the current asynchronous position).

I'm marking this as an anomaly for now. If you want to process mouse updates in
a tight loop then you need to use 'wait with messages' (but be careful about
re-entrancy) so the engine continues to dispatch mouse events whilst you are in
your loop (you can always stop message delivery with lock messages).

I replied back that I had included the wait just in order to make things work.

It is expected behavior, though, as the mouse functions are designed to return information about the target event, down to the "mouseChar" level, and no further, and not the current state of affairs. Well and good, though I would have preferred to have it default to the other way around, which seems far, far more intuitive to me. Anyway, it is something new learned, and we go forward...

Craig

[SparkOut]

Mmmm. Nice to get Mark's take on it, and it does make a bit of sense. But it isn't limited to mouse events. It's bad form to waste cycles updating a field within a repeat loop, but

Code: Select all

repeat with tLoop = 1 to 10000
  add 1 to field "fldTotal"
end repeat
 

will stop visibly adding numbers in the field and give a "(not responding)" caption in the title bar of the window, and in task manager on Windows. You have to let the engine and OS have an opportunity to pick up some cycles, which is introduced by the wait with messages. This is because the repeat loop is blocking - except how come it can still give cycles to the mouseLoc updates?

[dunbarx]

As I understand it, synchronicity is an engine attribute, hard coded.

So I made two buttons. In btn 1:

Code: Select all

on mouseUp
   repeat until the optionKey is down
      put the mouseLoc && the backColor of btn 2
      wait 10
   end repeat
end mouseUp

And in btn 2:

Code: Select all

on mouseUp
   setBackColor
end mouseUp

on setBackColor
   if the optionKey is down then exit to top
   set the backColor of btn 2 to any item of "red,green,blue,yellow,orange"
   send setBackColor to me in 10
end setBackColor

If I click on btn 2, to start the color changes, and then click on btn 1 to see what comes back, the mouseLoc tracks, but the backColor is locked to the backColor current when the click took place. Same for the "top", which is a property, unrelated to mouse functions. And now is it so for every property and function? I am not going to try them all

On the other hand, if in button 1:

Code: Select all

on mouseUp
   repeat until the optionKey is down
      put the mouseLoc && the backColor of btn 2
      set the backColor of btn 2 to any item of "red,green,blue,yellow,orange"
      wait 10
   end repeat
end mouseUp

This returns both. The backColor is set, and then the property is returned. Why should the backColor be "read" if in the same handler, but not if set in a different handler?

Craig