LiveCode is the premier environment for creating multi-platform solutions for all major operating systems - Windows, Mac OS X, Linux, the Web, Server environments and Mobile platforms. Brand new to LiveCode? Welcome!
on mouseDown theButton
put the label of me into myCounter
put myCounter into field fldCount
if theButton is 1 then
add 1 to myCounter
else if theButton is 3 then
if myCounter > 0 then
subtract 1 from myCounter
end if
end if
put myCounter into field fldCount
set the label of me to myCounter
end mouseDown
and just doing a rough test using the 1-second
tick of my study clock I'd say that the delay
between right mouse click has to be more
than one second - more like 2 seconds - for
it to subtract without getting confused.
Left click? Slow too because it really be
instantaneous I feel.
The stand-alone is no better and not putting
label into fldCount doesn't help either.
On a bit of a tangent, I was wondering whether the efficiency of the handler might be improved without the "if" clause and did the process mathematically like:
on mouseDown theButton
put the label of me into myCounter
add (2 - theButton) to myCounter
set the label of me to myCounter
end mouseDown
(and this is really a "wonder" - not saying that it should be, I'm fishing for some info, not stating a fact). Of course it's actually got nothing to do with the efficiency of the handler, rather the messages falling between mouseDown and mouseDoubleDown/mouseDoubleUp interpretation that's the problem.
on mouseUp theButton
put the label of me into myCounter
add (2 - theButton) to myCounter
set the label of me to max (0, myCounter)
end mouseUp
on mouseDoubleUp theButton
put the label of me into myCounter
add (2 - theButton) to myCounter
set the label of me to max (0, myCounter)
end mouseDoubleUp
My last post seems to have gone down
a black hole...
The required time between right mouse clicks
to avoid problems is over one second and
probably nearer two - rough test agains the
ticks of my study clock.
Left clicks are slow too but at least they always
add.
on mouseDown theButton
put the label of me into myCounter
---put myCounter into field fldCount
if theButton is 1 then
add 1 to myCounter
else if theButton is 3 then
if myCounter > 0 then
subtract 1 from myCounter
end if
end if
---put myCounter into field fldCount
set the label of me to myCounter
end mouseDown
Well did you try what has been suggested and change mouseDown to mouseUp? Also did you try adding a mouseDoubleUp handler? What happens if you replace the code in the button with the code I put above - including the mouseDoubleUp handler?
The reason you are getting problem results seems to be that there has to be a minimum delay between clicks in order to get a mouseDown/Up message - otherwise the mouseDoubleDown/Up message will be generated. On Mac/Linux the doubleClickInterval can be set (in milliseconds) but on Windows it is a read only property and will be read from the host system. If you're using Windows, in the control panel settings for the mouse do you have a slow double-click speed set?
If you are clicking quickly on the count button then to catch the messages you need to have the mouseDoubleUp handler in place as well as the single click handler. Also for whatever reason, the mouseDown response seems to be less consistent than mouseUp/mouseDoubleUp - so try that and see if it helps.
please try the combination of mouseUp and mouseDoubleUp as has been suggested, including code, by SparkOut and me in this thread and see if it makes a difference.
Rev documentation wrote:If the mouse has moved outside the control that was originally clicked before the user releases the mouse button, the mouseRelease message is sent instead of mouseUp. If the click is the second click of a double click, the mouseDoubleUp message is sent instead of mouseUp.
Tip: If the user clicks several times in rapid succession (for example, if the user clicks an "Increase" button that increases a number by 1), some of the clicks may send a mouseDoubleUp message instead of mouseUp. If your script only handles the mouseUp message, these accidental double clicks will be lost. One way to prevent this is to install a handler in an object that's further in the message path, to re-send double clicks: [...and goes on to give sample code...]
or in the case of a simple handler like this situation, repeat for mouseDoubleUp events.
I've tried many possible combinations -
except mouseSideways and mouseInTheBin
but the result seems to be that two fast
right-clicks results in the action of one left-click
i.e. 1 added when one would expect either
1 subtracted (if either click was "lost") or
no action if they're interpreted as a double-click.
Then there's the slow response time which
definitely should be better than it is.
In "olden times" when typists could easily
outpace the speed of the computer the keyboard
had a "buffer" which held key-presses until
the programme was ready for the next character.
There is a mouse click handler on your computer which interprets single clicks as single clicks and clicks which are very close together as double-clicks. This is what you are no doubt used to in operating your computer applications. Rev is behaving in exactly the way you'd expect as far as deciding whether a click is to be registered as a click or whether it's part of a double-click combination. (Putting two button 3 clicks together to make button 1 responses is another matter BUT it has absolutely no bearing on the issue you can solve by simply adding the mouseDoubleUp handler.) The reason there is a "delay" is because if you are clicking rapidly, then clicks within the interval set on your computer control panel are interpreted as mouseDoubleUp events - and if you have no handler for these events, then the mouse clicks are lost.
I have put your stack with this revised script on my RevOnline space. Please try that. It works perfectly here.
I have tested SparkOut's stack. If I try a double-click, assumingly it executes a mouseDoubleUp and a mouseUp (I'm having an issue with the script editor while writing this, so I can't look at the script in the default button on that stack).
I think we are mixing up a few problems, here. One of them being that after a mouseDoubleUp the mouseUp handler still runs. This is "normal" behaviour, designed by Bill Atkinson himself. Read more here:
The biggest LiveCode group on Facebook: https://www.facebook.com/groups/livecode.developers The book "Programming LiveCode for the Real Beginner"! Get it here! http://tinyurl.com/book-livecode
I have tested SparkOut's stack. If I try a double-click, assumingly it executes a mouseDoubleUp and a mouseUp (I'm having an issue with the script editor while writing this, so I can't look at the script in the default button on that stack).
Yes, there's a mouseUp which is handled for the first click, and when followed quickly by another it invokes the mouseDoubleUp instead. So for two clicks (in quick succession) you'll get two handlers invoked, but only one of each mouseUp and mouseDoubleUp. That means that to increment the button by one for each and every click, then both the mouseUp and mouseDoubleUp handlers should increment the count by 1. (Not as may be thought that the mouseDoubleUp would block the mouseUp and have to increment the counter twice). This is covered in the Rev dictionary (at least in version 2.8.1-gm3 onwards, maybe prior to that but I don't have a copy to check) as quoted in my post above.
Mark wrote:I think we are mixing up a few problems, here. One of them being that after a mouseDoubleUp the mouseUp handler still runs. This is "normal" behaviour, designed by Bill Atkinson himself. Read more here:
Quite why there are two messages for mouseDoubleDown I don't know, and that's probably got something to do with why the "Up" way works a lot better.
And Bernd, thanks. I was looking for some thoughts on that - I believe that mathematical processes like that must be more efficient than conditional tests, but I don't know how to make a definitive comparison.
when I'm clicking the button which has mouseUp and mouseDoubleUp handlers specified. I changed the handlers to mouseDown and mouseDoubleDown to see how that affected things and try to follow the messages. The results where that for 10 "rapid" (left)clicks the counter was incremented by a total of 15, and for 10 "rapid" right-clicks the counter was decremented by a total of 5 (it was possible to see the label being set down by two and then having an extra count added back).
In this case, following the messages I observed:
mouseDown
mouseUp
mouseDoubleDown
mouseDoubleDown
mouseDown
mouseUp
Which has baffled me. The messages that are triggered should be the same, regardless of what handlers have been set to catch them, isn't that correct? How can changing the handlers in a button actually change the messages that are generated by the clicking actions?
on mouseUp pMouseBtnNo
put 10000 into tRounds -- adjust the rounds here
put the millisec into tStartMath
repeat for tRounds
put 3 into theButton
put 5 into myCounter
add (2 - theButton) to myCounter
put max (0, myCounter) into tLabelVariable
put max (0, myCounter) into tFieldVariable
end repeat
put the millisec - tStartMath into tTimeForMath
put the millisec into tStartIF
repeat for tRounds
put 3 into theButton
put 5 into myCounter
if theButton = 1 then
add 1 to myCounter
else if theButton is 3 then
if theButton > 1 then
subtract 1 from myCounter
end if
end if
end repeat
put the millisec -tStartIF into tTimeForIF
put "Time for math " & tTimeForMath & return & "Time for IF " & tTimeForIF
end mouseUp
Assuming this reflects the core differences between the two approaches the IF-Then is faster to my surprise, still I like the beauty of the math approach. And since on a macbook pro 10000 times for math is around 14 millisecs and for IF-Then 9 millisecs, it is not that much of a difference. Unless you do it for many many times like in working on imagedata, where you easily do stuff like this in the million.
