Set DoubleClickInterval very low!

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Set DoubleClickInterval very low!

Sannyasin Brahmanathaswami
For Mobile newbies

Is your Mobile App Slow to Respond to Taps?

the default doubleclickinterval for LC is 800 milliseconds. This is nearly 1 whole second the engine waits before doing anything with your click/tap.

This carries over to your mobile app. No wonder the app feels sluggish and doesn't feel like it gets the user's taps

do this

on preopenstack
set the doubleclickinterval to 100
# other initializations…
end preopenstack

At least in our new app, it suddenly came alive!

BR
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Set DoubleClickInterval very low!

Richard Gaskin
Sannyasin Brahmanathaswami wrote:

 > For Mobile newbies
 >
 > Is your Mobile App Slow to Respond to Taps?
 >
 > the default doubleclickinterval for LC is 800 milliseconds. This is
 > nearly 1 whole second the engine waits before doing anything with
 > your click/tap.
 >
 > This carries over to your mobile app. No wonder the app feels
 > sluggish and doesn't feel like it gets the user's taps
 >
 > do this
 >
 > on preopenstack
 > set the doubleclickinterval to 100
 > # other initializations…
 > end preopenstack
 >
 > At least in our new app, it suddenly came alive!


The doubleClickInterval governs the durations between two clicks to
determine if the pair of clicks should be interpreted as a double-click.

With any single-click gesture there is of course no interval, so any
effect you may see with changing the doubleClickInterval with any
single-click gesture would be a bug and should be reported with a recipe
that will let the team fix it quickly.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Set DoubleClickInterval very low!

Sannyasin Brahmanathaswami
How is it a bug? logically the engine must wait for the double click interval before responding or double clicks could never be passed? N'est ce pas?

BR
: Richard Gaskin wrote:

With any single-click gesture there is of course no interval, so any
effect you may see with changing the doubleClickInterval with any
single-click gesture would be a bug and should be reported with a recipe
that will let the team fix it quickly.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Set DoubleClickInterval very low!

Mark Waddingham-2
On 2016-08-04 01:32, Sannyasin Brahmanathaswami wrote:
> How is it a bug? logically the engine must wait for the double click
> interval before responding or double clicks could never be passed?
> N'est ce pas?

No - that isn't how double clicks work in LiveCode.

On the first mouseDown the engine:

   1) Stores the time of the mouseDown (last-click-time)
   2) Stores the location of the mouseDown (last-click-loc)
   3) Dispatches mouseDown

On a subsequent mouseDown the engine does the following:

   if current-click-time - last-click-time < doubleClickInterval and \
        abs(current-click-loc.x - click-loc.x) < doubleClickDelta and \
           abs(current-click-loc.y - click-loc.y) < doubleClickDelta then
       dispatch mouseDoubleDown
   else
       dispatch mouseDown
   end if

i.e. If a click is within the doubleClickInterval time-wise since the
last click, and within the doubleClickDelta distance since the last
click a mouseDoubleDown message is sent instead of mouseDown.

(Note that if a mouse down event results in a mouseDown message, then
you will receive a mouseUp message when the mouse is released, and if a
mouse down even results in a mouseDoubleDown message, then you will
receive a mouseDoubleUp message when the mouse is released).

What you are seeing is the fact that if you tap quickly (i.e. each one
within the doubleClickInterval and close to each other on the screen)
then you will receive:

   mouseDown
   mouseUp
   mouseDoubleDown
   mouseDoubleUp
   mouseDown
   mouseUp
   mouseDoubleDown
   mouseDoubleUp

i.e. You will get an alternating sequence of down/up and
doubleDown/doubleUp pairs.

Solution: If you don't need to handle double clicks do:

   on mouseDoubleDown
     mouseDown
   end mouseDoubleDown

   on mouseDoubleUp
     mouseUp
   end mouseDoubleUp

This is a long standing (i.e. forever!) 'the way things work' in
LiveCode - although I think there is a way it could be a great deal
better, and more intuitive.

The only use of multi-click 'gestures' (which is what 'double clicks'
are) which makes sense from a UI interaction point of view is where each
click builds upon the action of the previous one.

e.g. In Finder:

   1) The first click selects a file
   2) The second click runs the file (which is already selected at this
point)

e.g. In Text Editors:

   1) The first click places the caret
   2) The second click selects the word the caret is in
   3) The third click selects the line the word is in

Thus, one possible improvement would be to ditch the 'double' messages
entirely, and add a 'clickCount' event property (a bit like the
clickLoc) which returns the number of subsequent clicks. This would mean
that (in a mouseDown / Up) handler you just choose what you do based on
the clickCount. This means you can easily handle single, double or
triple click sequences (which, I think is pretty much as far as you can
stretch that particular bit of physical interaction - unless you want to
cause the user significant problems in using your UI). i.e. In a double
click scenario you would get:

   mouseDown (clickCount == 1)
   mouseUp (clickCount == 1)
   mouseDown (clickCount == 2)
   mouseUp (clickCount == 2)

This can be further built upon by introducing the idea of gestures. A
'click' is actually a gesture, not an event - i.e. it is a precise
sequence of events which can be interpreted as a specific type of
action. Introducing gestures you'd get the following message sequence:

   mouseDown (clickCount == 1)
   mouseUp (clickCount == 1)
   click (clickCount == 1)
   mouseDown (clickCount == 2)
   mouseUp (clickCount == 2)
   doubleClick (clickCount == 2)
     if passed then click (clickCount == 2)

For what its worth, LiveCode Builder uses the clickCount model (i.e. no
double messages) - although we haven't added 'gestures' there yet.

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Set DoubleClickInterval very low!

Richard Gaskin
Mark Waddingham wrote:

 > On 2016-08-04 01:32, Sannyasin Brahmanathaswami wrote:
 >> How is it a bug? logically the engine must wait for the double click
 >> interval before responding or double clicks could never be passed?
 >> N'est ce pas?
 >
 > No - that isn't how double clicks work in LiveCode.

I think LC's implementation is similar to how most OSes handle it, at
least judging from the old Inside Mac details on click interval and slop
rect, and the XP refs I used to read.

Given that, I'm not sure we need to have you spend time away from other
tasks to explore this:

 > This is a long standing (i.e. forever!) 'the way things work' in
 > LiveCode - although I think there is a way it could be a great deal
 > better, and more intuitive.
 >
 > The only use of multi-click 'gestures' (which is what 'double clicks'
 > are) which makes sense from a UI interaction point of view is where
 > each
 > click builds upon the action of the previous one.
 >
 > e.g. In Finder:
 >
 >    1) The first click selects a file
 >    2) The second click runs the file (which is already selected at
 >        this point)
 >
 > e.g. In Text Editors:
 >
 >    1) The first click places the caret
 >    2) The second click selects the word the caret is in
 >    3) The third click selects the line the word is in

Those are both very good examples of the noun+verb interaction model for
applying commands to object in WOMPs, which personally I feel is
reasonably well supported in LC as it is.

In brief, we first select an object (noun), and then perform an action
on it (verb).

Often the action is a command chosen from a menu, which would then act
on whatever we'd selected.  But sometimes a shortcut is provided for a
menu action, such as in these examples with a second click.

In practice it's extremely rare that we find any object that truly
supports different actions on both single and double-clicks.

The Finder example *seems* at first glance like such a case, but as we
think about it more it becomes clear that no action ever takes place on
the first click, it's always just a selection; the second click is the
action, and which action it is will depend on the time/space constraints
from the first click.

Given all this, there may be other benefits to the proposed enhancements
you outlined, but so far it seems all practical needs for supporting
single- and double-clicks have been handled well with LC's current mouse
messages.

Indeed, for the rare case when one truly wants a single object to
support actions on both single- and double-clicks, we've seen examples
from the readers here of how we can keep track of the time between
clicks to support even that edge case.

Whether we keep track of the interval or the click count makes no
difference to me, but with the latter we'd still need to maintain an
awareness of the interval anyway, and best of all the current model is
already done and ready to use. :)

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Touch everywhere (was Re: Set DoubleClickInterval very low!)

Richard Gaskin
Earlier I wrote in reply to Mark Waddingham:
 > I think LC's implementation is similar to how most OSes handle it,
 > at least judging from the old Inside Mac details on click interval
 > and slop rect, and the XP refs I used to read.
 >
 > Given that, I'm not sure we need to have you spend time away from
 > other tasks to explore this...

I'd like to amend that with an exploratory idea:  supporting multitouch
on all platforms.

macOS currently supports touch gestures via the trackpad, and both
Windows and some Linux distros like Ubuntu and Mint support direct touch
on screen.

If we're going to explore possible extensions for what we currently
thing of as mouse messages, would it make sense to consider extending
that further to support multitouch on all platforms, desktoo and mobile
alike?

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Set DoubleClickInterval very low!

pmbrig
In reply to this post by Mark Waddingham-2
So I must not be understanding this. If you want something to happen on mouseup and something else to happen on mousedoubleup, then how do you do it?

If I put this into a button script:

on mousedown
   put "mousedown" & cr after fld "text"
end mousedown

on mouseUp
   put "mouseup" & cr after fld "text"
end mouseUp

on mousedoubledown
   put "mousedoubledown" & cr after fld "text"
end mousedoubledown

on mousedoubleup
   put "mousedoubleup" & cr after fld "text"
end mousedoubleup

and I then do a doubleclick, I get

mousedown
mouseup
mousedoubledown
mousedoubleup

in fld "text". So far so good. if I comment out the actions in the mousedown and mouseup handlers, so they are effectively blocking those messages, I get

mousedoubledown
mousedoubleup

in the field. But how do I get

mousedown
mouseup

on a single click and *only*

mousedoubledown
mousedoubleup

on a doubleclick?

It seems to me that if a doubleclick always produces both a mousedown/up and mousedoubledown/up set of messages, there is no way of preventing the mousedown/up actions happening in addition to the mousedoubledown/up actions. To make it clearer:

on mouseup
   show grc "test1"
end mouseup

on mousedoubleup
   show grc "test2"
end mousedoubleup

the mousedoubleup action will always show both graphics, but I want it to only show grc "test2".

???

-- Peter

Peter M. Brigham
[hidden email]

 

On Aug 3, 2016, at 7:55 PM, Mark Waddingham wrote:

> On 2016-08-04 01:32, Sannyasin Brahmanathaswami wrote:
>> How is it a bug? logically the engine must wait for the double click
>> interval before responding or double clicks could never be passed?
>> N'est ce pas?
>
> No - that isn't how double clicks work in LiveCode.
>
> On the first mouseDown the engine:
>
>  1) Stores the time of the mouseDown (last-click-time)
>  2) Stores the location of the mouseDown (last-click-loc)
>  3) Dispatches mouseDown
>
> On a subsequent mouseDown the engine does the following:
>
>  if current-click-time - last-click-time < doubleClickInterval and \
>       abs(current-click-loc.x - click-loc.x) < doubleClickDelta and \
>          abs(current-click-loc.y - click-loc.y) < doubleClickDelta then
>      dispatch mouseDoubleDown
>  else
>      dispatch mouseDown
>  end if
>
> i.e. If a click is within the doubleClickInterval time-wise since the last click, and within the doubleClickDelta distance since the last click a mouseDoubleDown message is sent instead of mouseDown.
>
> (Note that if a mouse down event results in a mouseDown message, then you will receive a mouseUp message when the mouse is released, and if a mouse down even results in a mouseDoubleDown message, then you will receive a mouseDoubleUp message when the mouse is released).
>
> What you are seeing is the fact that if you tap quickly (i.e. each one within the doubleClickInterval and close to each other on the screen) then you will receive:
>
>  mouseDown
>  mouseUp
>  mouseDoubleDown
>  mouseDoubleUp
>  mouseDown
>  mouseUp
>  mouseDoubleDown
>  mouseDoubleUp
>
> i.e. You will get an alternating sequence of down/up and doubleDown/doubleUp pairs.
>
> Solution: If you don't need to handle double clicks do:
>
>  on mouseDoubleDown
>    mouseDown
>  end mouseDoubleDown
>
>  on mouseDoubleUp
>    mouseUp
>  end mouseDoubleUp
>
> This is a long standing (i.e. forever!) 'the way things work' in LiveCode - although I think there is a way it could be a great deal better, and more intuitive.
>
> The only use of multi-click 'gestures' (which is what 'double clicks' are) which makes sense from a UI interaction point of view is where each click builds upon the action of the previous one.
>
> e.g. In Finder:
>
>  1) The first click selects a file
>  2) The second click runs the file (which is already selected at this point)
>
> e.g. In Text Editors:
>
>  1) The first click places the caret
>  2) The second click selects the word the caret is in
>  3) The third click selects the line the word is in
>
> Thus, one possible improvement would be to ditch the 'double' messages entirely, and add a 'clickCount' event property (a bit like the clickLoc) which returns the number of subsequent clicks. This would mean that (in a mouseDown / Up) handler you just choose what you do based on the clickCount. This means you can easily handle single, double or triple click sequences (which, I think is pretty much as far as you can stretch that particular bit of physical interaction - unless you want to cause the user significant problems in using your UI). i.e. In a double click scenario you would get:
>
>  mouseDown (clickCount == 1)
>  mouseUp (clickCount == 1)
>  mouseDown (clickCount == 2)
>  mouseUp (clickCount == 2)
>
> This can be further built upon by introducing the idea of gestures. A 'click' is actually a gesture, not an event - i.e. it is a precise sequence of events which can be interpreted as a specific type of action. Introducing gestures you'd get the following message sequence:
>
>  mouseDown (clickCount == 1)
>  mouseUp (clickCount == 1)
>  click (clickCount == 1)
>  mouseDown (clickCount == 2)
>  mouseUp (clickCount == 2)
>  doubleClick (clickCount == 2)
>    if passed then click (clickCount == 2)
>
> For what its worth, LiveCode Builder uses the clickCount model (i.e. no double messages) - although we haven't added 'gestures' there yet.
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Set DoubleClickInterval very low!

Sannyasin Brahmanathaswami
In reply to this post by Mark Waddingham-2
@ Mark

Thank you for the explanation. I would have to study this out more to reply with anything more intelligent.

Suffice it to say that

set the doubleClickInterval to 100

Immediately turned our new app into a "snappy responsive" animal.

Which is good, because the prevailing thought was beginning to become "Livecode is really to slow for mobile." when in fact, we just need to understand how to optimize things.

I will try adding the mouseDoubleDown and mouseDoubleUp traps you suggest to our main API.lc backscript for  all stacks in the framework.

We will face the requirement to taking action on a double click when that time comes. Our current multi-stack, module framework would allow us to simply set it for a given context and reset when leaving that context. So far I'm not seeing a single use case for a double click all our stacks.

I like your click count idea!

BR
On 8/3/16, 1:55 PM, "use-livecode on behalf of Mark Waddingham" <[hidden email] on behalf of [hidden email]> wrote:

    Solution: If you don't need to handle double clicks do:
   
       on mouseDoubleDown
         mouseDown
       end mouseDoubleDown
   
       on mouseDoubleUp
         mouseUp
       end mouseDoubleUp
   
    This is a long standing (i.e. forever!) 'the way things work' in
    LiveCode - although I think there is a way it could be a great deal
    better, and more intuitive.
   
   

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Set DoubleClickInterval very low!

Mark Waddingham-2
In reply to this post by pmbrig
In order for you to be able to do completely different things on click and double click you need to wait and see if a double click occurs before the doubleClickInterval and if it does not *then* do the single click action. After all, the engine is not clairvoyant.

This is why click then double click should always be an incremental and related action - unless you want a pause in processing the single click.

Mark.

Sent from my iPhone

> On 4 Aug 2016, at 03:14, Peter M. Brigham <[hidden email]> wrote:
>
> So I must not be understanding this. If you want something to happen on mouseup and something else to happen on mousedoubleup, then how do you do it?
>
> If I put this into a button script:
>
> on mousedown
>   put "mousedown" & cr after fld "text"
> end mousedown
>
> on mouseUp
>   put "mouseup" & cr after fld "text"
> end mouseUp
>
> on mousedoubledown
>   put "mousedoubledown" & cr after fld "text"
> end mousedoubledown
>
> on mousedoubleup
>   put "mousedoubleup" & cr after fld "text"
> end mousedoubleup
>
> and I then do a doubleclick, I get
>
> mousedown
> mouseup
> mousedoubledown
> mousedoubleup
>
> in fld "text". So far so good. if I comment out the actions in the mousedown and mouseup handlers, so they are effectively blocking those messages, I get
>
> mousedoubledown
> mousedoubleup
>
> in the field. But how do I get
>
> mousedown
> mouseup
>
> on a single click and *only*
>
> mousedoubledown
> mousedoubleup
>
> on a doubleclick?
>
> It seems to me that if a doubleclick always produces both a mousedown/up and mousedoubledown/up set of messages, there is no way of preventing the mousedown/up actions happening in addition to the mousedoubledown/up actions. To make it clearer:
>
> on mouseup
>   show grc "test1"
> end mouseup
>
> on mousedoubleup
>   show grc "test2"
> end mousedoubleup
>
> the mousedoubleup action will always show both graphics, but I want it to only show grc "test2".
>
> ???
>
> -- Peter
>
> Peter M. Brigham
> [hidden email]
>
>
>
>> On Aug 3, 2016, at 7:55 PM, Mark Waddingham wrote:
>>
>>> On 2016-08-04 01:32, Sannyasin Brahmanathaswami wrote:
>>> How is it a bug? logically the engine must wait for the double click
>>> interval before responding or double clicks could never be passed?
>>> N'est ce pas?
>>
>> No - that isn't how double clicks work in LiveCode.
>>
>> On the first mouseDown the engine:
>>
>> 1) Stores the time of the mouseDown (last-click-time)
>> 2) Stores the location of the mouseDown (last-click-loc)
>> 3) Dispatches mouseDown
>>
>> On a subsequent mouseDown the engine does the following:
>>
>> if current-click-time - last-click-time < doubleClickInterval and \
>>      abs(current-click-loc.x - click-loc.x) < doubleClickDelta and \
>>         abs(current-click-loc.y - click-loc.y) < doubleClickDelta then
>>     dispatch mouseDoubleDown
>> else
>>     dispatch mouseDown
>> end if
>>
>> i.e. If a click is within the doubleClickInterval time-wise since the last click, and within the doubleClickDelta distance since the last click a mouseDoubleDown message is sent instead of mouseDown.
>>
>> (Note that if a mouse down event results in a mouseDown message, then you will receive a mouseUp message when the mouse is released, and if a mouse down even results in a mouseDoubleDown message, then you will receive a mouseDoubleUp message when the mouse is released).
>>
>> What you are seeing is the fact that if you tap quickly (i.e. each one within the doubleClickInterval and close to each other on the screen) then you will receive:
>>
>> mouseDown
>> mouseUp
>> mouseDoubleDown
>> mouseDoubleUp
>> mouseDown
>> mouseUp
>> mouseDoubleDown
>> mouseDoubleUp
>>
>> i.e. You will get an alternating sequence of down/up and doubleDown/doubleUp pairs.
>>
>> Solution: If you don't need to handle double clicks do:
>>
>> on mouseDoubleDown
>>   mouseDown
>> end mouseDoubleDown
>>
>> on mouseDoubleUp
>>   mouseUp
>> end mouseDoubleUp
>>
>> This is a long standing (i.e. forever!) 'the way things work' in LiveCode - although I think there is a way it could be a great deal better, and more intuitive.
>>
>> The only use of multi-click 'gestures' (which is what 'double clicks' are) which makes sense from a UI interaction point of view is where each click builds upon the action of the previous one.
>>
>> e.g. In Finder:
>>
>> 1) The first click selects a file
>> 2) The second click runs the file (which is already selected at this point)
>>
>> e.g. In Text Editors:
>>
>> 1) The first click places the caret
>> 2) The second click selects the word the caret is in
>> 3) The third click selects the line the word is in
>>
>> Thus, one possible improvement would be to ditch the 'double' messages entirely, and add a 'clickCount' event property (a bit like the clickLoc) which returns the number of subsequent clicks. This would mean that (in a mouseDown / Up) handler you just choose what you do based on the clickCount. This means you can easily handle single, double or triple click sequences (which, I think is pretty much as far as you can stretch that particular bit of physical interaction - unless you want to cause the user significant problems in using your UI). i.e. In a double click scenario you would get:
>>
>> mouseDown (clickCount == 1)
>> mouseUp (clickCount == 1)
>> mouseDown (clickCount == 2)
>> mouseUp (clickCount == 2)
>>
>> This can be further built upon by introducing the idea of gestures. A 'click' is actually a gesture, not an event - i.e. it is a precise sequence of events which can be interpreted as a specific type of action. Introducing gestures you'd get the following message sequence:
>>
>> mouseDown (clickCount == 1)
>> mouseUp (clickCount == 1)
>> click (clickCount == 1)
>> mouseDown (clickCount == 2)
>> mouseUp (clickCount == 2)
>> doubleClick (clickCount == 2)
>>   if passed then click (clickCount == 2)
>>
>> For what its worth, LiveCode Builder uses the clickCount model (i.e. no double messages) - although we haven't added 'gestures' there yet.
>>
>> Warmest Regards,
>>
>> Mark.
>>
>> --
>> Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
>> LiveCode: Everyone can create apps
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Set DoubleClickInterval very low!

Mark Waddingham-2
In reply to this post by Richard Gaskin
All I was pointing out was that the current mechanism means you need to put in shim doubleMouse handlers in the controls which don't respond to double clicks *and* you have to write more code if you want to handle triple click.

A simpler pattern (I think at least) is the one I suggested where you get no doubleMouse messages but can get easily how many clicks have occurred in the current sequence.

This topic I think has come up several times over the years which suggests that the current behavior isn't perhaps the most obvious (and is ever so slightly misleading) however, admittedly, it is perhaps less important than other things if only because it is all scriptable - you just need to think how to script it.

Mark.

Sent from my iPhone

> On 4 Aug 2016, at 01:35, Richard Gaskin <[hidden email]> wrote:
>
> Mark Waddingham wrote:
>
> > On 2016-08-04 01:32, Sannyasin Brahmanathaswami wrote:
> >> How is it a bug? logically the engine must wait for the double click
> >> interval before responding or double clicks could never be passed?
> >> N'est ce pas?
> >
> > No - that isn't how double clicks work in LiveCode.
>
> I think LC's implementation is similar to how most OSes handle it, at least judging from the old Inside Mac details on click interval and slop rect, and the XP refs I used to read.
>
> Given that, I'm not sure we need to have you spend time away from other tasks to explore this:
>
> > This is a long standing (i.e. forever!) 'the way things work' in
> > LiveCode - although I think there is a way it could be a great deal
> > better, and more intuitive.
> >
> > The only use of multi-click 'gestures' (which is what 'double clicks'
> > are) which makes sense from a UI interaction point of view is where
> > each
> > click builds upon the action of the previous one.
> >
> > e.g. In Finder:
> >
> >    1) The first click selects a file
> >    2) The second click runs the file (which is already selected at
> >        this point)
> >
> > e.g. In Text Editors:
> >
> >    1) The first click places the caret
> >    2) The second click selects the word the caret is in
> >    3) The third click selects the line the word is in
>
> Those are both very good examples of the noun+verb interaction model for applying commands to object in WOMPs, which personally I feel is reasonably well supported in LC as it is.
>
> In brief, we first select an object (noun), and then perform an action on it (verb).
>
> Often the action is a command chosen from a menu, which would then act on whatever we'd selected.  But sometimes a shortcut is provided for a menu action, such as in these examples with a second click.
>
> In practice it's extremely rare that we find any object that truly supports different actions on both single and double-clicks.
>
> The Finder example *seems* at first glance like such a case, but as we think about it more it becomes clear that no action ever takes place on the first click, it's always just a selection; the second click is the action, and which action it is will depend on the time/space constraints from the first click.
>
> Given all this, there may be other benefits to the proposed enhancements you outlined, but so far it seems all practical needs for supporting single- and double-clicks have been handled well with LC's current mouse messages.
>
> Indeed, for the rare case when one truly wants a single object to support actions on both single- and double-clicks, we've seen examples from the readers here of how we can keep track of the time between clicks to support even that edge case.
>
> Whether we keep track of the interval or the click count makes no difference to me, but with the latter we'd still need to maintain an awareness of the interval anyway, and best of all the current model is already done and ready to use. :)
>
> --
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> ____________________________________________________________________
> [hidden email]                http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Extracting list of errors from LiveCode 8

Lyn Teyla
Hi all,

In LiveCode 7 and earlier, one could use the following to extract the list of errors:

the cErrorsList of cd 1 of stack "revErrorDisplay"

However, this no longer works in LiveCode 8.

What is the new method of extracting the list of errors?

TIA,
Lyn



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Extracting list of errors from LiveCode 8

Thierry Douez
Hi Lyn,

within LC 8.0, this works:

*put* the cErrorsList of stack "revErrorDisplay"

​Regards,

Thierry



> In LiveCode 7 and earlier, one could use the following to extract the list
> of errors:
>
> the cErrorsList of cd 1 of stack "revErrorDisplay"
>
> However, this no longer works in LiveCode 8.
>
> What is the new method of extracting the list of errors?
>
> TIA,
> Lyn
>
> ------------------------------------------------
Thierry Douez - http://sunny-tdz.com
sunnYrex - sunnYtext2speech - sunnYperl - sunnYmidi - sunnYmage
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Extracting list of errors from LiveCode 8

Lyn Teyla
Thierry Douez wrote:

> within LC 8.0, this works:
>
> *put* the cErrorsList of stack "revErrorDisplay"


Thanks Thierry!

However, this doesn’t seem to work with 8.0.2 RC 4 and 8.1.0 DP 3.

Lyn



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Extracting list of errors from LiveCode 8

Ali Lloyd-2
You can use the global property

the scriptExecutionErrors

To obtain this list. Note that this does not work in a standalone so if you
need it you'll have to set a custom property on an included stack or
something like that.

On Thu, 4 Aug 2016 at 10:29, Lyn Teyla <[hidden email]> wrote:

> Thierry Douez wrote:
>
> > within LC 8.0, this works:
> >
> > *put* the cErrorsList of stack "revErrorDisplay"
>
>
> Thanks Thierry!
>
> However, this doesn’t seem to work with 8.0.2 RC 4 and 8.1.0 DP 3.
>
> Lyn
>
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Set DoubleClickInterval very low!

pmbrig
In reply to this post by Mark Waddingham-2
That's what I thought. The engine is certainly not clairvoyant. I can script around this. I was hoping that the newer LC versions had somehow made it easier to do different things with single and double clicks, since I'm not sure why you would ever want a doubleclick to default to including the single click action too. Your ideas for fixing this with the clickcount method sound good, as it would allow the engine to sort out the clicks so as to obviate the need for additional scripting.

-- Peter

Peter M. Brigham
[hidden email]


On Aug 4, 2016, at 3:02 AM, Mark Waddingham wrote:

> In order for you to be able to do completely different things on click and double click you need to wait and see if a double click occurs before the doubleClickInterval and if it does not *then* do the single click action. After all, the engine is not clairvoyant.
>
> This is why click then double click should always be an incremental and related action - unless you want a pause in processing the single click.
>
> Mark.
>
> Sent from my iPhone
>
>> On 4 Aug 2016, at 03:14, Peter M. Brigham <[hidden email]> wrote:
>>
>> So I must not be understanding this. If you want something to happen on mouseup and something else to happen on mousedoubleup, then how do you do it?
>>
>> If I put this into a button script:
>>
>> on mousedown
>>  put "mousedown" & cr after fld "text"
>> end mousedown
>>
>> on mouseUp
>>  put "mouseup" & cr after fld "text"
>> end mouseUp
>>
>> on mousedoubledown
>>  put "mousedoubledown" & cr after fld "text"
>> end mousedoubledown
>>
>> on mousedoubleup
>>  put "mousedoubleup" & cr after fld "text"
>> end mousedoubleup
>>
>> and I then do a doubleclick, I get
>>
>> mousedown
>> mouseup
>> mousedoubledown
>> mousedoubleup
>>
>> in fld "text". So far so good. if I comment out the actions in the mousedown and mouseup handlers, so they are effectively blocking those messages, I get
>>
>> mousedoubledown
>> mousedoubleup
>>
>> in the field. But how do I get
>>
>> mousedown
>> mouseup
>>
>> on a single click and *only*
>>
>> mousedoubledown
>> mousedoubleup
>>
>> on a doubleclick?
>>
>> It seems to me that if a doubleclick always produces both a mousedown/up and mousedoubledown/up set of messages, there is no way of preventing the mousedown/up actions happening in addition to the mousedoubledown/up actions. To make it clearer:
>>
>> on mouseup
>>  show grc "test1"
>> end mouseup
>>
>> on mousedoubleup
>>  show grc "test2"
>> end mousedoubleup
>>
>> the mousedoubleup action will always show both graphics, but I want it to only show grc "test2".
>>
>> ???
>>
>> -- Peter
>>
>> Peter M. Brigham
>> [hidden email]
>>
>>
>>
>>> On Aug 3, 2016, at 7:55 PM, Mark Waddingham wrote:
>>>
>>>> On 2016-08-04 01:32, Sannyasin Brahmanathaswami wrote:
>>>> How is it a bug? logically the engine must wait for the double click
>>>> interval before responding or double clicks could never be passed?
>>>> N'est ce pas?
>>>
>>> No - that isn't how double clicks work in LiveCode.
>>>
>>> On the first mouseDown the engine:
>>>
>>> 1) Stores the time of the mouseDown (last-click-time)
>>> 2) Stores the location of the mouseDown (last-click-loc)
>>> 3) Dispatches mouseDown
>>>
>>> On a subsequent mouseDown the engine does the following:
>>>
>>> if current-click-time - last-click-time < doubleClickInterval and \
>>>     abs(current-click-loc.x - click-loc.x) < doubleClickDelta and \
>>>        abs(current-click-loc.y - click-loc.y) < doubleClickDelta then
>>>    dispatch mouseDoubleDown
>>> else
>>>    dispatch mouseDown
>>> end if
>>>
>>> i.e. If a click is within the doubleClickInterval time-wise since the last click, and within the doubleClickDelta distance since the last click a mouseDoubleDown message is sent instead of mouseDown.
>>>
>>> (Note that if a mouse down event results in a mouseDown message, then you will receive a mouseUp message when the mouse is released, and if a mouse down even results in a mouseDoubleDown message, then you will receive a mouseDoubleUp message when the mouse is released).
>>>
>>> What you are seeing is the fact that if you tap quickly (i.e. each one within the doubleClickInterval and close to each other on the screen) then you will receive:
>>>
>>> mouseDown
>>> mouseUp
>>> mouseDoubleDown
>>> mouseDoubleUp
>>> mouseDown
>>> mouseUp
>>> mouseDoubleDown
>>> mouseDoubleUp
>>>
>>> i.e. You will get an alternating sequence of down/up and doubleDown/doubleUp pairs.
>>>
>>> Solution: If you don't need to handle double clicks do:
>>>
>>> on mouseDoubleDown
>>>  mouseDown
>>> end mouseDoubleDown
>>>
>>> on mouseDoubleUp
>>>  mouseUp
>>> end mouseDoubleUp
>>>
>>> This is a long standing (i.e. forever!) 'the way things work' in LiveCode - although I think there is a way it could be a great deal better, and more intuitive.
>>>
>>> The only use of multi-click 'gestures' (which is what 'double clicks' are) which makes sense from a UI interaction point of view is where each click builds upon the action of the previous one.
>>>
>>> e.g. In Finder:
>>>
>>> 1) The first click selects a file
>>> 2) The second click runs the file (which is already selected at this point)
>>>
>>> e.g. In Text Editors:
>>>
>>> 1) The first click places the caret
>>> 2) The second click selects the word the caret is in
>>> 3) The third click selects the line the word is in
>>>
>>> Thus, one possible improvement would be to ditch the 'double' messages entirely, and add a 'clickCount' event property (a bit like the clickLoc) which returns the number of subsequent clicks. This would mean that (in a mouseDown / Up) handler you just choose what you do based on the clickCount. This means you can easily handle single, double or triple click sequences (which, I think is pretty much as far as you can stretch that particular bit of physical interaction - unless you want to cause the user significant problems in using your UI). i.e. In a double click scenario you would get:
>>>
>>> mouseDown (clickCount == 1)
>>> mouseUp (clickCount == 1)
>>> mouseDown (clickCount == 2)
>>> mouseUp (clickCount == 2)
>>>
>>> This can be further built upon by introducing the idea of gestures. A 'click' is actually a gesture, not an event - i.e. it is a precise sequence of events which can be interpreted as a specific type of action. Introducing gestures you'd get the following message sequence:
>>>
>>> mouseDown (clickCount == 1)
>>> mouseUp (clickCount == 1)
>>> click (clickCount == 1)
>>> mouseDown (clickCount == 2)
>>> mouseUp (clickCount == 2)
>>> doubleClick (clickCount == 2)
>>>  if passed then click (clickCount == 2)
>>>
>>> For what its worth, LiveCode Builder uses the clickCount model (i.e. no double messages) - although we haven't added 'gestures' there yet.
>>>
>>> Warmest Regards,
>>>
>>> Mark.
>>>
>>> --
>>> Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
>>> LiveCode: Everyone can create apps
>>>
>>> _______________________________________________
>>> use-livecode mailing list
>>> [hidden email]
>>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Set DoubleClickInterval very low!

Richard Gaskin
In reply to this post by pmbrig
Peter M. Brigham wrote:
 > So I must not be understanding this. If you want something to happen
 > on mouseup and something else to happen on mousedoubleup, then how
 > do you do it?

The other question is *why* would you do it?

A control usually has an interaction semantics role of either a verb or
a noun.  A push button, for example, is a verb, performing an action,
while a Finder icon is a noun, where it must be selected first and then
use some other control as the verb (usually a menu item) to apply an
action to it.  Sometimes a noun object may also support a shortcut for
the verb object, such as a second click on the noun object, but the
essential role of the noun object remains fairly consistent throughout
the interactions, in which the first click merely selects the object and
performs no action.

When determining whether a circumstance is an edge case or a common one,
I like the rule of three:  Can you think of three examples in apps from
established vendors like Apple where a control acts as both a verb and a
noun, i.e. provides a direct action on a single-click and then a
different action on a double-click?

In the rare case where this may be useful in a context that doesn't
confuse or frustrate the user (accidental double-clicks are not
uncommon), the OS routines that differentiate single- and double-clicks
would require a pause equal to the OS' doubleClickInterval, as
Mark noted:

    In order for you to be able to do completely different things
    on click and double click you need to wait and see if a double
    click occurs before the doubleClickInterval and if it does not
    *then* do the single click action. After all, the engine is
    not clairvoyant.

    This is why click then double click should always be an incremental
    and related action - unless you want a pause in processing the
    single click.


This has come up a few times on this list over the years, and while I
generally try to avoid mixing verb/noun semantics and don't have one
handy, I would imagine a search at Nabble may help, or perhaps Michael
Doub has already included such an example in his Master Library stack.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Set DoubleClickInterval very low!

Richard Gaskin
In reply to this post by Sannyasin Brahmanathaswami
Sannyasin Brahmanathaswami wrote:

 > Suffice it to say that
 >
 > set the doubleClickInterval to 100
 >
 > Immediately turned our new app into a "snappy responsive" animal.
 >
 > Which is good, because the prevailing thought was beginning to become
 > "Livecode is really to slow for mobile." when in fact, we just need
 > to understand how to optimize things.

That "optimization" should not be needed, for the reasons Mark described.

Unless you have some other factor at play there, changing the value of
any property not related to an action should never be needed, and should
be considered a bug.

With a single-click, the doubleClickInterval should be no more relevant
than the moveSpeed or anything else unrelated to the action.

If this is consistently reproducible please file a bug report.  We can't
expect newcomers to hunt down all possible combinations of unrelated
properties just to make a button respond to a click appropriately.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Set DoubleClickInterval very low!

Richard Gaskin
A moment ago I wrote:
 > Unless you have some other factor at play there, changing the value
 > of any property not related to an action should never be needed, and
 > should be considered a bug.

The first clause is key there.  I haven't spent much time with iOS yet,
and perhaps there's a bug in LC's engine for that platform, but on
Android (and all desktop engines) LC responds to single-clicks/taps
instantly as expected.

Could it be that you have a mouseUp handler, perhaps in a library
somewhere, that attempts to differentiate single- and double-clicks for
a given object?

If so, my earlier notes about the noun+verb interaction semantics may be
either helpful or irritating depending on your mood <g>, but moreover
reducing the doubleClickInterval below the default OS threshold would
result in confusion for the user, in which double-clicks happen far less
frequently than they've become accustomed to.

I would review your libraries first, and if you have no mouseUp handlers
waiting for the doubleClickInterval then I'd file a bug report.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Set DoubleClickInterval very low!

Sannyasin Brahmanathaswami
In reply to this post by Mark Waddingham-2
@ Mark
which confirms that lowering the doubleClick Interval to thereby increase responsiveness of a single click is not a bug, but, just the way it works…

 

On 8/3/16, 9:02 PM, "use-livecode on behalf of Mark Waddingham" <[hidden email] on behalf of [hidden email]> wrote:

    In order for you to be able to do completely different things on click and double click you need to wait and see if a double click occurs before the doubleClickInterval and if it does not *then* do the single click action. After all, the engine is not clairvoyant.
   
    This is why click then double click should always be an incremental and related action - unless you want a pause in processing the single clic

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Extracting list of errors from LiveCode 8

Sannyasin Brahmanathaswami
In reply to this post by Ali Lloyd-2
FYI, not all errors from all included plug-ins will show  with the scriptExecutionErrors.

e.g. libURL errors can silently lock up the entire IDE and you will only know if explicitly check for the result at the right place in your script.

 
On 8/3/16, 11:59 PM, "use-livecode on behalf of Ali Lloyd" <[hidden email] on behalf of [hidden email]> wrote:

    You can use the global property
   
    the scriptExecutionErrors
   
    To obtain this list. Note that this does not work in a standalone so if you
    need it you'll have to set a custom property on an included stack or
    something like that.

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
12