Detect scroll activity (when LC is not frontmost)

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

Re: Detect scroll activity (when LC is not frontmost)

Paul Dupuis
On 12/25/2016 10:05 AM, Terry Vogelaar wrote:
> So it starts to become clear that it might not be possible to do what I want. Although I hope to be wrong about that.

I think it is very unlikely you can do this in LC - without externals or
LCB widgets from "infinite Livecode".

The active mouse and keyboard drivers capture events from these devices
and pass that information to the operating system, which massages the
data and passed a higher level of events on to the active application,
which looks for such events and handles them. In the case of the
LiveCode engine - or any app built on the LC engine - that is executing
applicable messages for your scripts to handle.

Most productivity tracking software works by effectively inserting code
into where the device drivers meet the operating system, so that mouse
and keyboard events are captured by the productivity app's as well as
being sent by the OS to the active application as normal.

Using LCB and LC9.0 you might be able to write an LCB widget that does
this, but I am not familiar enough with current OSX APIs for event
capture or drivers under OSX to or the state of work in LC9.0 on
integrating OS API calls to say for sure.

You are unlikely to be able to do what you want in LiveCode script alone.


_______________________________________________
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: Detect scroll activity (when LC is not frontmost)

Mike Bonner
I have an answer..

Heres a sample script:
local sRunning

on mouseUp
if sRunning is empty then put false into sRunning
put not sRunning into sRunning
loopit
end mouseUp

command loopit
if sRunning then
put the last word of (shell("ioreg -c IOHIDSystem |grep Idle")) into tIdle
put tIdle / 1000000000 into field 1
send "loopit" to me in 2 sec
end if
end loopit

The script is in a button, and I have a single field on the card.  The math
is done to convert to seconds of idle.

The are only 2 disclaimers here.  First is that the value returned pre 10.3
is hex so you'd have to handle that if you have an earlier osx.  10.3 and
after this solution should work fine.

The second issue is is that on mac 10.12, the idle time won't update on
typing.  Its an osx issue for that specific version, but worst case you
already have a method to track keypresses.

On Sun, Dec 25, 2016 at 8:21 AM, Paul Dupuis <[hidden email]> wrote:

> On 12/25/2016 10:05 AM, Terry Vogelaar wrote:
> > So it starts to become clear that it might not be possible to do what I
> want. Although I hope to be wrong about that.
>
> I think it is very unlikely you can do this in LC - without externals or
> LCB widgets from "infinite Livecode".
>
> The active mouse and keyboard drivers capture events from these devices
> and pass that information to the operating system, which massages the
> data and passed a higher level of events on to the active application,
> which looks for such events and handles them. In the case of the
> LiveCode engine - or any app built on the LC engine - that is executing
> applicable messages for your scripts to handle.
>
> Most productivity tracking software works by effectively inserting code
> into where the device drivers meet the operating system, so that mouse
> and keyboard events are captured by the productivity app's as well as
> being sent by the OS to the active application as normal.
>
> Using LCB and LC9.0 you might be able to write an LCB widget that does
> this, but I am not familiar enough with current OSX APIs for event
> capture or drivers under OSX to or the state of work in LC9.0 on
> integrating OS API calls to say for sure.
>
> You are unlikely to be able to do what you want in LiveCode script alone.
>
>
> _______________________________________________
> 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: Detect scroll activity (when LC is not frontmost)

Richmond Mathewson-2
Does that mean that if, say, I have a stack running your script in the
stackScript
and I'm scrolling a window in Firefox that that scrolling will register
in the LC stack?

The reason I am asking that question is because I don't quite understand
how one effect a mouseUp
while one is scrolling with one's mouse at the same time and the mouseUp
not affecting the frontmost app.

Richmond.

On 12/25/16 5:56 pm, Mike Bonner wrote:

> I have an answer..
>
> Heres a sample script:
> local sRunning
>
> on mouseUp
> if sRunning is empty then put false into sRunning
> put not sRunning into sRunning
> loopit
> end mouseUp
>
> command loopit
> if sRunning then
> put the last word of (shell("ioreg -c IOHIDSystem |grep Idle")) into tIdle
> put tIdle / 1000000000 into field 1
> send "loopit" to me in 2 sec
> end if
> end loopit
>
> The script is in a button, and I have a single field on the card.  The math
> is done to convert to seconds of idle.
>
> The are only 2 disclaimers here.  First is that the value returned pre 10.3
> is hex so you'd have to handle that if you have an earlier osx.  10.3 and
> after this solution should work fine.
>
> The second issue is is that on mac 10.12, the idle time won't update on
> typing.  Its an osx issue for that specific version, but worst case you
> already have a method to track keypresses.
>
> On Sun, Dec 25, 2016 at 8:21 AM, Paul Dupuis <[hidden email]> wrote:
>
>> On 12/25/2016 10:05 AM, Terry Vogelaar wrote:
>>> So it starts to become clear that it might not be possible to do what I
>> want. Although I hope to be wrong about that.
>>
>> I think it is very unlikely you can do this in LC - without externals or
>> LCB widgets from "infinite Livecode".
>>
>> The active mouse and keyboard drivers capture events from these devices
>> and pass that information to the operating system, which massages the
>> data and passed a higher level of events on to the active application,
>> which looks for such events and handles them. In the case of the
>> LiveCode engine - or any app built on the LC engine - that is executing
>> applicable messages for your scripts to handle.
>>
>> Most productivity tracking software works by effectively inserting code
>> into where the device drivers meet the operating system, so that mouse
>> and keyboard events are captured by the productivity app's as well as
>> being sent by the OS to the active application as normal.
>>
>> Using LCB and LC9.0 you might be able to write an LCB widget that does
>> this, but I am not familiar enough with current OSX APIs for event
>> capture or drivers under OSX to or the state of work in LC9.0 on
>> integrating OS API calls to say for sure.
>>
>> You are unlikely to be able to do what you want in LiveCode script alone.
>>
>>
>> _______________________________________________
>> 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: Detect scroll activity (when LC is not frontmost)

Richmond Mathewson-2
In reply to this post by Mike Bonner
I have just tried this:

1. When the stack is frontMost it puts

a large digit number (5-8 after the decimal point) into the field at all
sorts of
intervals.

There is no obvious connexion between any of these numbers and the keys
I am currently bashing on
to type this message, nor when I use the scroll wheel on my mouse,

numbers are changing even when I am doing nothing beyod sitting here
with my mouth open
watching the stack and wondering how those numbers can be shown to have
any direct
correspondence with any user input.

2. Certainly the stack is picking something up, but if it is detecting
scroll activity it is not doing it
in any obviously useful fashion.

Richmond.

On 12/25/16 5:56 pm, Mike Bonner wrote:

> I have an answer..
>
> Heres a sample script:
> local sRunning
>
> on mouseUp
> if sRunning is empty then put false into sRunning
> put not sRunning into sRunning
> loopit
> end mouseUp
>
> command loopit
> if sRunning then
> put the last word of (shell("ioreg -c IOHIDSystem |grep Idle")) into tIdle
> put tIdle / 1000000000 into field 1
> send "loopit" to me in 2 sec
> end if
> end loopit
>
> The script is in a button, and I have a single field on the card.  The math
> is done to convert to seconds of idle.
>
> The are only 2 disclaimers here.  First is that the value returned pre 10.3
> is hex so you'd have to handle that if you have an earlier osx.  10.3 and
> after this solution should work fine.
>
> The second issue is is that on mac 10.12, the idle time won't update on
> typing.  Its an osx issue for that specific version, but worst case you
> already have a method to track keypresses.
>
> On Sun, Dec 25, 2016 at 8:21 AM, Paul Dupuis <[hidden email]> wrote:
>
>> On 12/25/2016 10:05 AM, Terry Vogelaar wrote:
>>> So it starts to become clear that it might not be possible to do what I
>> want. Although I hope to be wrong about that.
>>
>> I think it is very unlikely you can do this in LC - without externals or
>> LCB widgets from "infinite Livecode".
>>
>> The active mouse and keyboard drivers capture events from these devices
>> and pass that information to the operating system, which massages the
>> data and passed a higher level of events on to the active application,
>> which looks for such events and handles them. In the case of the
>> LiveCode engine - or any app built on the LC engine - that is executing
>> applicable messages for your scripts to handle.
>>
>> Most productivity tracking software works by effectively inserting code
>> into where the device drivers meet the operating system, so that mouse
>> and keyboard events are captured by the productivity app's as well as
>> being sent by the OS to the active application as normal.
>>
>> Using LCB and LC9.0 you might be able to write an LCB widget that does
>> this, but I am not familiar enough with current OSX APIs for event
>> capture or drivers under OSX to or the state of work in LC9.0 on
>> integrating OS API calls to say for sure.
>>
>> You are unlikely to be able to do what you want in LiveCode script alone.
>>
>>
>> _______________________________________________
>> 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: Detect scroll activity (when LC is not frontmost)

Mike Bonner
In reply to this post by Richmond Mathewson-2
The script does an end run of the whole situation.  The os itself is
keeping track of the idle time between user events.  All the script does is
grab the current value. And since only HID (human interface devices) are
tracked, any mouse/keyboard activity in any app of the system will reset
the timer.  So technically no, the scroll won't "register" in the lc stack
(meaning it won't cause a handler to fire), but the OS does track HID
actions..  All the stack does is request the information from the os (in a
loop), that information being the time since the last user activity.



On Sun, Dec 25, 2016 at 9:29 AM, Richmond Mathewson <
[hidden email]> wrote:

> Does that mean that if, say, I have a stack running your script in the
> stackScript
> and I'm scrolling a window in Firefox that that scrolling will register in
> the LC stack?
>
> The reason I am asking that question is because I don't quite understand
> how one effect a mouseUp
> while one is scrolling with one's mouse at the same time and the mouseUp
> not affecting the frontmost app.
>
> Richmond.
>
>
> On 12/25/16 5:56 pm, Mike Bonner wrote:
>
>> I have an answer..
>>
>> Heres a sample script:
>> local sRunning
>>
>> on mouseUp
>> if sRunning is empty then put false into sRunning
>> put not sRunning into sRunning
>> loopit
>> end mouseUp
>>
>> command loopit
>> if sRunning then
>> put the last word of (shell("ioreg -c IOHIDSystem |grep Idle")) into tIdle
>> put tIdle / 1000000000 into field 1
>> send "loopit" to me in 2 sec
>> end if
>> end loopit
>>
>> The script is in a button, and I have a single field on the card.  The
>> math
>> is done to convert to seconds of idle.
>>
>> The are only 2 disclaimers here.  First is that the value returned pre
>> 10.3
>> is hex so you'd have to handle that if you have an earlier osx.  10.3 and
>> after this solution should work fine.
>>
>> The second issue is is that on mac 10.12, the idle time won't update on
>> typing.  Its an osx issue for that specific version, but worst case you
>> already have a method to track keypresses.
>>
>> On Sun, Dec 25, 2016 at 8:21 AM, Paul Dupuis <[hidden email]>
>> wrote:
>>
>> On 12/25/2016 10:05 AM, Terry Vogelaar wrote:
>>>
>>>> So it starts to become clear that it might not be possible to do what I
>>>>
>>> want. Although I hope to be wrong about that.
>>>
>>> I think it is very unlikely you can do this in LC - without externals or
>>> LCB widgets from "infinite Livecode".
>>>
>>> The active mouse and keyboard drivers capture events from these devices
>>> and pass that information to the operating system, which massages the
>>> data and passed a higher level of events on to the active application,
>>> which looks for such events and handles them. In the case of the
>>> LiveCode engine - or any app built on the LC engine - that is executing
>>> applicable messages for your scripts to handle.
>>>
>>> Most productivity tracking software works by effectively inserting code
>>> into where the device drivers meet the operating system, so that mouse
>>> and keyboard events are captured by the productivity app's as well as
>>> being sent by the OS to the active application as normal.
>>>
>>> Using LCB and LC9.0 you might be able to write an LCB widget that does
>>> this, but I am not familiar enough with current OSX APIs for event
>>> capture or drivers under OSX to or the state of work in LC9.0 on
>>> integrating OS API calls to say for sure.
>>>
>>> You are unlikely to be able to do what you want in LiveCode script alone.
>>>
>>>
>>> _______________________________________________
>>> 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: Detect scroll activity (when LC is not frontmost)

Mike Bonner
In reply to this post by Richmond Mathewson-2
Using my script, the numbers will change every 2 seconds.  If you do
nothing and watch the numbers, the digits to the left of the decimal should
increase by approximately 2 each cycle.
If you type, scroll, whatever, the number should shrink (possibly even a 0
to the left of the decimal)

What version of osx are you using?

On Sun, Dec 25, 2016 at 9:39 AM, Richmond Mathewson <
[hidden email]> wrote:

> I have just tried this:
>
> 1. When the stack is frontMost it puts
>
> a large digit number (5-8 after the decimal point) into the field at all
> sorts of
> intervals.
>
> There is no obvious connexion between any of these numbers and the keys I
> am currently bashing on
> to type this message, nor when I use the scroll wheel on my mouse,
>
> numbers are changing even when I am doing nothing beyod sitting here with
> my mouth open
> watching the stack and wondering how those numbers can be shown to have
> any direct
> correspondence with any user input.
>
> 2. Certainly the stack is picking something up, but if it is detecting
> scroll activity it is not doing it
> in any obviously useful fashion.
>
> Richmond.
>
> On 12/25/16 5:56 pm, Mike Bonner wrote:
>
>> I have an answer..
>>
>> Heres a sample script:
>> local sRunning
>>
>> on mouseUp
>> if sRunning is empty then put false into sRunning
>> put not sRunning into sRunning
>> loopit
>> end mouseUp
>>
>> command loopit
>> if sRunning then
>> put the last word of (shell("ioreg -c IOHIDSystem |grep Idle")) into tIdle
>> put tIdle / 1000000000 into field 1
>> send "loopit" to me in 2 sec
>> end if
>> end loopit
>>
>> The script is in a button, and I have a single field on the card.  The
>> math
>> is done to convert to seconds of idle.
>>
>> The are only 2 disclaimers here.  First is that the value returned pre
>> 10.3
>> is hex so you'd have to handle that if you have an earlier osx.  10.3 and
>> after this solution should work fine.
>>
>> The second issue is is that on mac 10.12, the idle time won't update on
>> typing.  Its an osx issue for that specific version, but worst case you
>> already have a method to track keypresses.
>>
>> On Sun, Dec 25, 2016 at 8:21 AM, Paul Dupuis <[hidden email]>
>> wrote:
>>
>> On 12/25/2016 10:05 AM, Terry Vogelaar wrote:
>>>
>>>> So it starts to become clear that it might not be possible to do what I
>>>>
>>> want. Although I hope to be wrong about that.
>>>
>>> I think it is very unlikely you can do this in LC - without externals or
>>> LCB widgets from "infinite Livecode".
>>>
>>> The active mouse and keyboard drivers capture events from these devices
>>> and pass that information to the operating system, which massages the
>>> data and passed a higher level of events on to the active application,
>>> which looks for such events and handles them. In the case of the
>>> LiveCode engine - or any app built on the LC engine - that is executing
>>> applicable messages for your scripts to handle.
>>>
>>> Most productivity tracking software works by effectively inserting code
>>> into where the device drivers meet the operating system, so that mouse
>>> and keyboard events are captured by the productivity app's as well as
>>> being sent by the OS to the active application as normal.
>>>
>>> Using LCB and LC9.0 you might be able to write an LCB widget that does
>>> this, but I am not familiar enough with current OSX APIs for event
>>> capture or drivers under OSX to or the state of work in LC9.0 on
>>> integrating OS API calls to say for sure.
>>>
>>> You are unlikely to be able to do what you want in LiveCode script alone.
>>>
>>>
>>> _______________________________________________
>>> 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: Detect scroll activity (when LC is not frontmost)

Richmond Mathewson-2
In reply to this post by Mike Bonner
Aha: thanks.

On 12/25/16 6:39 pm, Mike Bonner wrote:
> The script does an end run of the whole situation.  The os itself is
> keeping track of the idle time between user events.  All the script does is
> grab the current value. And since only HID (human interface devices) are
> tracked, any mouse/keyboard activity in any app of the system will reset
> the timer.  So technically no, the scroll won't "register" in the lc stack
> (meaning it won't cause a handler to fire), but the OS does track HID
> actions..  All the stack does is request the information from the os (in a
> loop), that information being the time since the last user activity.

So, the inevitable question is how one would use an idle time value to tell
one that the end-user his performed a scroll (and whether up or down),
as all
those idle time values are are times in (?) micro-seconds.

I assume (?) that, somewhere in the belly of the beast (Mac OS) a HID
performed action
must register as such, and also as WHICH HID was used, and WHAT action
was performed on
that HID.

A forward scroll on my Belkin Nostromo is just as much a forward scroll
as one on my mighty mouse.

The question that started this thread concerns NOT whether one can pick
up signals that HIDs are
being used, but when they ARE being used, which of the activities being
performed is a scroll.

This seems remarkably like the problem with other people:

1. We can generally tell when brain activity is going on in other people
(however, c.f. catatonia),
and we can stick electrodes into parts of the human brain so that we can
pick up electric pulses
that tell us when the brain is receiving signals from outside the body.

2. What cannot (as far as I am aware) be worked out (if one is not
cheating and looking at who
is poking your volunteer in the stomach with a chopstick) is what is
being done to make the brain
register those signals.

Richmond.

>
>
>
> On Sun, Dec 25, 2016 at 9:29 AM, Richmond Mathewson <
> [hidden email]> wrote:
>
>> Does that mean that if, say, I have a stack running your script in the
>> stackScript
>> and I'm scrolling a window in Firefox that that scrolling will register in
>> the LC stack?
>>
>> The reason I am asking that question is because I don't quite understand
>> how one effect a mouseUp
>> while one is scrolling with one's mouse at the same time and the mouseUp
>> not affecting the frontmost app.
>>
>> Richmond.
>>
>>
>> On 12/25/16 5:56 pm, Mike Bonner wrote:
>>
>>> I have an answer..
>>>
>>> Heres a sample script:
>>> local sRunning
>>>
>>> on mouseUp
>>> if sRunning is empty then put false into sRunning
>>> put not sRunning into sRunning
>>> loopit
>>> end mouseUp
>>>
>>> command loopit
>>> if sRunning then
>>> put the last word of (shell("ioreg -c IOHIDSystem |grep Idle")) into tIdle
>>> put tIdle / 1000000000 into field 1
>>> send "loopit" to me in 2 sec
>>> end if
>>> end loopit
>>>
>>> The script is in a button, and I have a single field on the card.  The
>>> math
>>> is done to convert to seconds of idle.
>>>
>>> The are only 2 disclaimers here.  First is that the value returned pre
>>> 10.3
>>> is hex so you'd have to handle that if you have an earlier osx.  10.3 and
>>> after this solution should work fine.
>>>
>>> The second issue is is that on mac 10.12, the idle time won't update on
>>> typing.  Its an osx issue for that specific version, but worst case you
>>> already have a method to track keypresses.
>>>
>>> On Sun, Dec 25, 2016 at 8:21 AM, Paul Dupuis <[hidden email]>
>>> wrote:
>>>
>>> On 12/25/2016 10:05 AM, Terry Vogelaar wrote:
>>>>> So it starts to become clear that it might not be possible to do what I
>>>>>
>>>> want. Although I hope to be wrong about that.
>>>>
>>>> I think it is very unlikely you can do this in LC - without externals or
>>>> LCB widgets from "infinite Livecode".
>>>>
>>>> The active mouse and keyboard drivers capture events from these devices
>>>> and pass that information to the operating system, which massages the
>>>> data and passed a higher level of events on to the active application,
>>>> which looks for such events and handles them. In the case of the
>>>> LiveCode engine - or any app built on the LC engine - that is executing
>>>> applicable messages for your scripts to handle.
>>>>
>>>> Most productivity tracking software works by effectively inserting code
>>>> into where the device drivers meet the operating system, so that mouse
>>>> and keyboard events are captured by the productivity app's as well as
>>>> being sent by the OS to the active application as normal.
>>>>
>>>> Using LCB and LC9.0 you might be able to write an LCB widget that does
>>>> this, but I am not familiar enough with current OSX APIs for event
>>>> capture or drivers under OSX to or the state of work in LC9.0 on
>>>> integrating OS API calls to say for sure.
>>>>
>>>> You are unlikely to be able to do what you want in LiveCode script alone.
>>>>
>>>>
>>>> _______________________________________________
>>>> 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

_______________________________________________
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: Detect scroll activity (when LC is not frontmost)

Richmond Mathewson-2
In reply to this post by Mike Bonner
Aha.

On 12/25/16 6:42 pm, Mike Bonner wrote:
> Using my script, the numbers will change every 2 seconds.  If you do
> nothing and watch the numbers, the digits to the left of the decimal should
> increase by approximately 2 each cycle.
> If you type, scroll, whatever, the number should shrink (possibly even a 0
> to the left of the decimal)

The problem lies in the word "whatever".

A scroll may shrink the number; so may other things; and that's the rub.

I've got a pain in my stomach:

1. Wind?

2. Acidity?

3. Swallowed a paperclip?

The pain is not sufficient in and of itself to work out what the cause
of the pain is.
>
> What version of osx are you using?

I'm using Mac OS 10.7.5

Richmond.

>
> On Sun, Dec 25, 2016 at 9:39 AM, Richmond Mathewson <
> [hidden email]> wrote:
>
>> I have just tried this:
>>
>> 1. When the stack is frontMost it puts
>>
>> a large digit number (5-8 after the decimal point) into the field at all
>> sorts of
>> intervals.
>>
>> There is no obvious connexion between any of these numbers and the keys I
>> am currently bashing on
>> to type this message, nor when I use the scroll wheel on my mouse,
>>
>> numbers are changing even when I am doing nothing beyod sitting here with
>> my mouth open
>> watching the stack and wondering how those numbers can be shown to have
>> any direct
>> correspondence with any user input.
>>
>> 2. Certainly the stack is picking something up, but if it is detecting
>> scroll activity it is not doing it
>> in any obviously useful fashion.
>>
>> Richmond.
>>
>> On 12/25/16 5:56 pm, Mike Bonner wrote:
>>
>>> I have an answer..
>>>
>>> Heres a sample script:
>>> local sRunning
>>>
>>> on mouseUp
>>> if sRunning is empty then put false into sRunning
>>> put not sRunning into sRunning
>>> loopit
>>> end mouseUp
>>>
>>> command loopit
>>> if sRunning then
>>> put the last word of (shell("ioreg -c IOHIDSystem |grep Idle")) into tIdle
>>> put tIdle / 1000000000 into field 1
>>> send "loopit" to me in 2 sec
>>> end if
>>> end loopit
>>>
>>> The script is in a button, and I have a single field on the card.  The
>>> math
>>> is done to convert to seconds of idle.
>>>
>>> The are only 2 disclaimers here.  First is that the value returned pre
>>> 10.3
>>> is hex so you'd have to handle that if you have an earlier osx.  10.3 and
>>> after this solution should work fine.
>>>
>>> The second issue is is that on mac 10.12, the idle time won't update on
>>> typing.  Its an osx issue for that specific version, but worst case you
>>> already have a method to track keypresses.
>>>
>>> On Sun, Dec 25, 2016 at 8:21 AM, Paul Dupuis <[hidden email]>
>>> wrote:
>>>
>>> On 12/25/2016 10:05 AM, Terry Vogelaar wrote:
>>>>> So it starts to become clear that it might not be possible to do what I
>>>>>
>>>> want. Although I hope to be wrong about that.
>>>>
>>>> I think it is very unlikely you can do this in LC - without externals or
>>>> LCB widgets from "infinite Livecode".
>>>>
>>>> The active mouse and keyboard drivers capture events from these devices
>>>> and pass that information to the operating system, which massages the
>>>> data and passed a higher level of events on to the active application,
>>>> which looks for such events and handles them. In the case of the
>>>> LiveCode engine - or any app built on the LC engine - that is executing
>>>> applicable messages for your scripts to handle.
>>>>
>>>> Most productivity tracking software works by effectively inserting code
>>>> into where the device drivers meet the operating system, so that mouse
>>>> and keyboard events are captured by the productivity app's as well as
>>>> being sent by the OS to the active application as normal.
>>>>
>>>> Using LCB and LC9.0 you might be able to write an LCB widget that does
>>>> this, but I am not familiar enough with current OSX APIs for event
>>>> capture or drivers under OSX to or the state of work in LC9.0 on
>>>> integrating OS API calls to say for sure.
>>>>
>>>> You are unlikely to be able to do what you want in LiveCode script alone.
>>>>
>>>>
>>>> _______________________________________________
>>>> 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

_______________________________________________
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: Detect scroll activity (when LC is not frontmost)

Mike Bonner
In reply to this post by Richmond Mathewson-2
Actually, the question boils down to "is the user active."  not "what key
is pressed, was a screen scrolled(using what device) , or what button was
clicked."  I could be wrong. /shrug  The only recent issue that needed to
be solved is that scroll is an activity too, and there was no easy way to
get lc to see that as an action.

This ignores the whole question and lets lc poll the os to see if there was
any HID action at all-- this (if I understand correctly)  being the
ultimate goal.
So yeah, if you scroll with you belkin, its a scroll.  As on a mighty
mouse. But for this purpose (again, if I understand correctly)  it doesn't
matter.  An action of any type, by a user (typing, scrolling, clicking,
using a touch screen) shows that the user is actually sitting at the
computer.

If you have a different needs that just tracking idle/active time, this is
not for you.
Otherwise, there is no longer a need to look at keysdown() or
mousescreenloc at all.  Just grab the number from the os. If the mouse has
moved recently, it'll be small. Same for keypresses, scrolls, clicks,
screen touches.

So as in the example of catatonia.. Was it a poke, a tickle, a prod, a
kick..  If all you're looking for is signs of brain activity, it doesn't
matter.  (simplified of course, because in those cases examining responses
to different stimuli DOES matter during evaluation.. but not so with the
desired goal)

On Sun, Dec 25, 2016 at 9:51 AM, Richmond Mathewson <
[hidden email]> wrote:

> Aha: thanks.
>
> On 12/25/16 6:39 pm, Mike Bonner wrote:
>
>> The script does an end run of the whole situation.  The os itself is
>> keeping track of the idle time between user events.  All the script does
>> is
>> grab the current value. And since only HID (human interface devices) are
>> tracked, any mouse/keyboard activity in any app of the system will reset
>> the timer.  So technically no, the scroll won't "register" in the lc stack
>> (meaning it won't cause a handler to fire), but the OS does track HID
>> actions..  All the stack does is request the information from the os (in a
>> loop), that information being the time since the last user activity.
>>
>
> So, the inevitable question is how one would use an idle time value to tell
> one that the end-user his performed a scroll (and whether up or down), as
> all
> those idle time values are are times in (?) micro-seconds.
>
> I assume (?) that, somewhere in the belly of the beast (Mac OS) a HID
> performed action
> must register as such, and also as WHICH HID was used, and WHAT action was
> performed on
> that HID.
>
> A forward scroll on my Belkin Nostromo is just as much a forward scroll as
> one on my mighty mouse.
>
> The question that started this thread concerns NOT whether one can pick up
> signals that HIDs are
> being used, but when they ARE being used, which of the activities being
> performed is a scroll.
>
> This seems remarkably like the problem with other people:
>
> 1. We can generally tell when brain activity is going on in other people
> (however, c.f. catatonia),
> and we can stick electrodes into parts of the human brain so that we can
> pick up electric pulses
> that tell us when the brain is receiving signals from outside the body.
>
> 2. What cannot (as far as I am aware) be worked out (if one is not
> cheating and looking at who
> is poking your volunteer in the stomach with a chopstick) is what is being
> done to make the brain
> register those signals.
>
> Richmond.
>
>
>>
>>
>> On Sun, Dec 25, 2016 at 9:29 AM, Richmond Mathewson <
>> [hidden email]> wrote:
>>
>> Does that mean that if, say, I have a stack running your script in the
>>> stackScript
>>> and I'm scrolling a window in Firefox that that scrolling will register
>>> in
>>> the LC stack?
>>>
>>> The reason I am asking that question is because I don't quite understand
>>> how one effect a mouseUp
>>> while one is scrolling with one's mouse at the same time and the mouseUp
>>> not affecting the frontmost app.
>>>
>>> Richmond.
>>>
>>>
>>> On 12/25/16 5:56 pm, Mike Bonner wrote:
>>>
>>> I have an answer..
>>>>
>>>> Heres a sample script:
>>>> local sRunning
>>>>
>>>> on mouseUp
>>>> if sRunning is empty then put false into sRunning
>>>> put not sRunning into sRunning
>>>> loopit
>>>> end mouseUp
>>>>
>>>> command loopit
>>>> if sRunning then
>>>> put the last word of (shell("ioreg -c IOHIDSystem |grep Idle")) into
>>>> tIdle
>>>> put tIdle / 1000000000 into field 1
>>>> send "loopit" to me in 2 sec
>>>> end if
>>>> end loopit
>>>>
>>>> The script is in a button, and I have a single field on the card.  The
>>>> math
>>>> is done to convert to seconds of idle.
>>>>
>>>> The are only 2 disclaimers here.  First is that the value returned pre
>>>> 10.3
>>>> is hex so you'd have to handle that if you have an earlier osx.  10.3
>>>> and
>>>> after this solution should work fine.
>>>>
>>>> The second issue is is that on mac 10.12, the idle time won't update on
>>>> typing.  Its an osx issue for that specific version, but worst case you
>>>> already have a method to track keypresses.
>>>>
>>>> On Sun, Dec 25, 2016 at 8:21 AM, Paul Dupuis <[hidden email]>
>>>> wrote:
>>>>
>>>> On 12/25/2016 10:05 AM, Terry Vogelaar wrote:
>>>>
>>>>> So it starts to become clear that it might not be possible to do what I
>>>>>>
>>>>>> want. Although I hope to be wrong about that.
>>>>>
>>>>> I think it is very unlikely you can do this in LC - without externals
>>>>> or
>>>>> LCB widgets from "infinite Livecode".
>>>>>
>>>>> The active mouse and keyboard drivers capture events from these devices
>>>>> and pass that information to the operating system, which massages the
>>>>> data and passed a higher level of events on to the active application,
>>>>> which looks for such events and handles them. In the case of the
>>>>> LiveCode engine - or any app built on the LC engine - that is executing
>>>>> applicable messages for your scripts to handle.
>>>>>
>>>>> Most productivity tracking software works by effectively inserting code
>>>>> into where the device drivers meet the operating system, so that mouse
>>>>> and keyboard events are captured by the productivity app's as well as
>>>>> being sent by the OS to the active application as normal.
>>>>>
>>>>> Using LCB and LC9.0 you might be able to write an LCB widget that does
>>>>> this, but I am not familiar enough with current OSX APIs for event
>>>>> capture or drivers under OSX to or the state of work in LC9.0 on
>>>>> integrating OS API calls to say for sure.
>>>>>
>>>>> You are unlikely to be able to do what you want in LiveCode script
>>>>> alone.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>
> _______________________________________________
> 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: Detect scroll activity (when LC is not frontmost)

Mike Bonner
And on that note, heading to see the family.  Merry (insert your own
acceptable season greeting or general wish for happiness here.)

On Sun, Dec 25, 2016 at 10:08 AM, Mike Bonner <[hidden email]> wrote:

> Actually, the question boils down to "is the user active."  not "what key
> is pressed, was a screen scrolled(using what device) , or what button was
> clicked."  I could be wrong. /shrug  The only recent issue that needed to
> be solved is that scroll is an activity too, and there was no easy way to
> get lc to see that as an action.
>
> This ignores the whole question and lets lc poll the os to see if there
> was any HID action at all-- this (if I understand correctly)  being the
> ultimate goal.
> So yeah, if you scroll with you belkin, its a scroll.  As on a mighty
> mouse. But for this purpose (again, if I understand correctly)  it doesn't
> matter.  An action of any type, by a user (typing, scrolling, clicking,
> using a touch screen) shows that the user is actually sitting at the
> computer.
>
> If you have a different needs that just tracking idle/active time, this is
> not for you.
> Otherwise, there is no longer a need to look at keysdown() or
> mousescreenloc at all.  Just grab the number from the os. If the mouse has
> moved recently, it'll be small. Same for keypresses, scrolls, clicks,
> screen touches.
>
> So as in the example of catatonia.. Was it a poke, a tickle, a prod, a
> kick..  If all you're looking for is signs of brain activity, it doesn't
> matter.  (simplified of course, because in those cases examining responses
> to different stimuli DOES matter during evaluation.. but not so with the
> desired goal)
>
> On Sun, Dec 25, 2016 at 9:51 AM, Richmond Mathewson <
> [hidden email]> wrote:
>
>> Aha: thanks.
>>
>> On 12/25/16 6:39 pm, Mike Bonner wrote:
>>
>>> The script does an end run of the whole situation.  The os itself is
>>> keeping track of the idle time between user events.  All the script does
>>> is
>>> grab the current value. And since only HID (human interface devices) are
>>> tracked, any mouse/keyboard activity in any app of the system will reset
>>> the timer.  So technically no, the scroll won't "register" in the lc
>>> stack
>>> (meaning it won't cause a handler to fire), but the OS does track HID
>>> actions..  All the stack does is request the information from the os (in
>>> a
>>> loop), that information being the time since the last user activity.
>>>
>>
>> So, the inevitable question is how one would use an idle time value to
>> tell
>> one that the end-user his performed a scroll (and whether up or down), as
>> all
>> those idle time values are are times in (?) micro-seconds.
>>
>> I assume (?) that, somewhere in the belly of the beast (Mac OS) a HID
>> performed action
>> must register as such, and also as WHICH HID was used, and WHAT action
>> was performed on
>> that HID.
>>
>> A forward scroll on my Belkin Nostromo is just as much a forward scroll
>> as one on my mighty mouse.
>>
>> The question that started this thread concerns NOT whether one can pick
>> up signals that HIDs are
>> being used, but when they ARE being used, which of the activities being
>> performed is a scroll.
>>
>> This seems remarkably like the problem with other people:
>>
>> 1. We can generally tell when brain activity is going on in other people
>> (however, c.f. catatonia),
>> and we can stick electrodes into parts of the human brain so that we can
>> pick up electric pulses
>> that tell us when the brain is receiving signals from outside the body.
>>
>> 2. What cannot (as far as I am aware) be worked out (if one is not
>> cheating and looking at who
>> is poking your volunteer in the stomach with a chopstick) is what is
>> being done to make the brain
>> register those signals.
>>
>> Richmond.
>>
>>
>>>
>>>
>>> On Sun, Dec 25, 2016 at 9:29 AM, Richmond Mathewson <
>>> [hidden email]> wrote:
>>>
>>> Does that mean that if, say, I have a stack running your script in the
>>>> stackScript
>>>> and I'm scrolling a window in Firefox that that scrolling will register
>>>> in
>>>> the LC stack?
>>>>
>>>> The reason I am asking that question is because I don't quite understand
>>>> how one effect a mouseUp
>>>> while one is scrolling with one's mouse at the same time and the mouseUp
>>>> not affecting the frontmost app.
>>>>
>>>> Richmond.
>>>>
>>>>
>>>> On 12/25/16 5:56 pm, Mike Bonner wrote:
>>>>
>>>> I have an answer..
>>>>>
>>>>> Heres a sample script:
>>>>> local sRunning
>>>>>
>>>>> on mouseUp
>>>>> if sRunning is empty then put false into sRunning
>>>>> put not sRunning into sRunning
>>>>> loopit
>>>>> end mouseUp
>>>>>
>>>>> command loopit
>>>>> if sRunning then
>>>>> put the last word of (shell("ioreg -c IOHIDSystem |grep Idle")) into
>>>>> tIdle
>>>>> put tIdle / 1000000000 into field 1
>>>>> send "loopit" to me in 2 sec
>>>>> end if
>>>>> end loopit
>>>>>
>>>>> The script is in a button, and I have a single field on the card.  The
>>>>> math
>>>>> is done to convert to seconds of idle.
>>>>>
>>>>> The are only 2 disclaimers here.  First is that the value returned pre
>>>>> 10.3
>>>>> is hex so you'd have to handle that if you have an earlier osx.  10.3
>>>>> and
>>>>> after this solution should work fine.
>>>>>
>>>>> The second issue is is that on mac 10.12, the idle time won't update on
>>>>> typing.  Its an osx issue for that specific version, but worst case you
>>>>> already have a method to track keypresses.
>>>>>
>>>>> On Sun, Dec 25, 2016 at 8:21 AM, Paul Dupuis <[hidden email]>
>>>>> wrote:
>>>>>
>>>>> On 12/25/2016 10:05 AM, Terry Vogelaar wrote:
>>>>>
>>>>>> So it starts to become clear that it might not be possible to do what
>>>>>>> I
>>>>>>>
>>>>>>> want. Although I hope to be wrong about that.
>>>>>>
>>>>>> I think it is very unlikely you can do this in LC - without externals
>>>>>> or
>>>>>> LCB widgets from "infinite Livecode".
>>>>>>
>>>>>> The active mouse and keyboard drivers capture events from these
>>>>>> devices
>>>>>> and pass that information to the operating system, which massages the
>>>>>> data and passed a higher level of events on to the active application,
>>>>>> which looks for such events and handles them. In the case of the
>>>>>> LiveCode engine - or any app built on the LC engine - that is
>>>>>> executing
>>>>>> applicable messages for your scripts to handle.
>>>>>>
>>>>>> Most productivity tracking software works by effectively inserting
>>>>>> code
>>>>>> into where the device drivers meet the operating system, so that mouse
>>>>>> and keyboard events are captured by the productivity app's as well as
>>>>>> being sent by the OS to the active application as normal.
>>>>>>
>>>>>> Using LCB and LC9.0 you might be able to write an LCB widget that does
>>>>>> this, but I am not familiar enough with current OSX APIs for event
>>>>>> capture or drivers under OSX to or the state of work in LC9.0 on
>>>>>> integrating OS API calls to say for sure.
>>>>>>
>>>>>> You are unlikely to be able to do what you want in LiveCode script
>>>>>> alone.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>
>>
>> _______________________________________________
>> 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: Detect scroll activity (when LC is not frontmost)

Mike Bonner
Really headed next door now but..
This is from the original poster..
"I’m working on a productivity & RSI prevention app. So I want to notice
activity while my project is not the frontmost application."

On Sun, Dec 25, 2016 at 10:08 AM, Mike Bonner <[hidden email]> wrote:

> And on that note, heading to see the family.  Merry (insert your own
> acceptable season greeting or general wish for happiness here.)
>
> On Sun, Dec 25, 2016 at 10:08 AM, Mike Bonner <[hidden email]> wrote:
>
>> Actually, the question boils down to "is the user active."  not "what key
>> is pressed, was a screen scrolled(using what device) , or what button was
>> clicked."  I could be wrong. /shrug  The only recent issue that needed to
>> be solved is that scroll is an activity too, and there was no easy way to
>> get lc to see that as an action.
>>
>> This ignores the whole question and lets lc poll the os to see if there
>> was any HID action at all-- this (if I understand correctly)  being the
>> ultimate goal.
>> So yeah, if you scroll with you belkin, its a scroll.  As on a mighty
>> mouse. But for this purpose (again, if I understand correctly)  it doesn't
>> matter.  An action of any type, by a user (typing, scrolling, clicking,
>> using a touch screen) shows that the user is actually sitting at the
>> computer.
>>
>> If you have a different needs that just tracking idle/active time, this
>> is not for you.
>> Otherwise, there is no longer a need to look at keysdown() or
>> mousescreenloc at all.  Just grab the number from the os. If the mouse has
>> moved recently, it'll be small. Same for keypresses, scrolls, clicks,
>> screen touches.
>>
>> So as in the example of catatonia.. Was it a poke, a tickle, a prod, a
>> kick..  If all you're looking for is signs of brain activity, it doesn't
>> matter.  (simplified of course, because in those cases examining responses
>> to different stimuli DOES matter during evaluation.. but not so with the
>> desired goal)
>>
>> On Sun, Dec 25, 2016 at 9:51 AM, Richmond Mathewson <
>> [hidden email]> wrote:
>>
>>> Aha: thanks.
>>>
>>> On 12/25/16 6:39 pm, Mike Bonner wrote:
>>>
>>>> The script does an end run of the whole situation.  The os itself is
>>>> keeping track of the idle time between user events.  All the script
>>>> does is
>>>> grab the current value. And since only HID (human interface devices) are
>>>> tracked, any mouse/keyboard activity in any app of the system will reset
>>>> the timer.  So technically no, the scroll won't "register" in the lc
>>>> stack
>>>> (meaning it won't cause a handler to fire), but the OS does track HID
>>>> actions..  All the stack does is request the information from the os
>>>> (in a
>>>> loop), that information being the time since the last user activity.
>>>>
>>>
>>> So, the inevitable question is how one would use an idle time value to
>>> tell
>>> one that the end-user his performed a scroll (and whether up or down),
>>> as all
>>> those idle time values are are times in (?) micro-seconds.
>>>
>>> I assume (?) that, somewhere in the belly of the beast (Mac OS) a HID
>>> performed action
>>> must register as such, and also as WHICH HID was used, and WHAT action
>>> was performed on
>>> that HID.
>>>
>>> A forward scroll on my Belkin Nostromo is just as much a forward scroll
>>> as one on my mighty mouse.
>>>
>>> The question that started this thread concerns NOT whether one can pick
>>> up signals that HIDs are
>>> being used, but when they ARE being used, which of the activities being
>>> performed is a scroll.
>>>
>>> This seems remarkably like the problem with other people:
>>>
>>> 1. We can generally tell when brain activity is going on in other people
>>> (however, c.f. catatonia),
>>> and we can stick electrodes into parts of the human brain so that we can
>>> pick up electric pulses
>>> that tell us when the brain is receiving signals from outside the body.
>>>
>>> 2. What cannot (as far as I am aware) be worked out (if one is not
>>> cheating and looking at who
>>> is poking your volunteer in the stomach with a chopstick) is what is
>>> being done to make the brain
>>> register those signals.
>>>
>>> Richmond.
>>>
>>>
>>>>
>>>>
>>>> On Sun, Dec 25, 2016 at 9:29 AM, Richmond Mathewson <
>>>> [hidden email]> wrote:
>>>>
>>>> Does that mean that if, say, I have a stack running your script in the
>>>>> stackScript
>>>>> and I'm scrolling a window in Firefox that that scrolling will
>>>>> register in
>>>>> the LC stack?
>>>>>
>>>>> The reason I am asking that question is because I don't quite
>>>>> understand
>>>>> how one effect a mouseUp
>>>>> while one is scrolling with one's mouse at the same time and the
>>>>> mouseUp
>>>>> not affecting the frontmost app.
>>>>>
>>>>> Richmond.
>>>>>
>>>>>
>>>>> On 12/25/16 5:56 pm, Mike Bonner wrote:
>>>>>
>>>>> I have an answer..
>>>>>>
>>>>>> Heres a sample script:
>>>>>> local sRunning
>>>>>>
>>>>>> on mouseUp
>>>>>> if sRunning is empty then put false into sRunning
>>>>>> put not sRunning into sRunning
>>>>>> loopit
>>>>>> end mouseUp
>>>>>>
>>>>>> command loopit
>>>>>> if sRunning then
>>>>>> put the last word of (shell("ioreg -c IOHIDSystem |grep Idle")) into
>>>>>> tIdle
>>>>>> put tIdle / 1000000000 into field 1
>>>>>> send "loopit" to me in 2 sec
>>>>>> end if
>>>>>> end loopit
>>>>>>
>>>>>> The script is in a button, and I have a single field on the card.  The
>>>>>> math
>>>>>> is done to convert to seconds of idle.
>>>>>>
>>>>>> The are only 2 disclaimers here.  First is that the value returned pre
>>>>>> 10.3
>>>>>> is hex so you'd have to handle that if you have an earlier osx.  10.3
>>>>>> and
>>>>>> after this solution should work fine.
>>>>>>
>>>>>> The second issue is is that on mac 10.12, the idle time won't update
>>>>>> on
>>>>>> typing.  Its an osx issue for that specific version, but worst case
>>>>>> you
>>>>>> already have a method to track keypresses.
>>>>>>
>>>>>> On Sun, Dec 25, 2016 at 8:21 AM, Paul Dupuis <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>> On 12/25/2016 10:05 AM, Terry Vogelaar wrote:
>>>>>>
>>>>>>> So it starts to become clear that it might not be possible to do
>>>>>>>> what I
>>>>>>>>
>>>>>>>> want. Although I hope to be wrong about that.
>>>>>>>
>>>>>>> I think it is very unlikely you can do this in LC - without
>>>>>>> externals or
>>>>>>> LCB widgets from "infinite Livecode".
>>>>>>>
>>>>>>> The active mouse and keyboard drivers capture events from these
>>>>>>> devices
>>>>>>> and pass that information to the operating system, which massages the
>>>>>>> data and passed a higher level of events on to the active
>>>>>>> application,
>>>>>>> which looks for such events and handles them. In the case of the
>>>>>>> LiveCode engine - or any app built on the LC engine - that is
>>>>>>> executing
>>>>>>> applicable messages for your scripts to handle.
>>>>>>>
>>>>>>> Most productivity tracking software works by effectively inserting
>>>>>>> code
>>>>>>> into where the device drivers meet the operating system, so that
>>>>>>> mouse
>>>>>>> and keyboard events are captured by the productivity app's as well as
>>>>>>> being sent by the OS to the active application as normal.
>>>>>>>
>>>>>>> Using LCB and LC9.0 you might be able to write an LCB widget that
>>>>>>> does
>>>>>>> this, but I am not familiar enough with current OSX APIs for event
>>>>>>> capture or drivers under OSX to or the state of work in LC9.0 on
>>>>>>> integrating OS API calls to say for sure.
>>>>>>>
>>>>>>> You are unlikely to be able to do what you want in LiveCode script
>>>>>>> alone.
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>
>>>
>>> _______________________________________________
>>> 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: Detect scroll activity (when LC is not frontmost)

Richmond Mathewson-2
Aha!

On 12/25/16 7:19 pm, Mike Bonner wrote:

> Really headed next door now but..
> This is from the original poster..
> "I’m working on a productivity & RSI prevention app. So I want to notice
> activity while my project is not the frontmost application."
>
> On Sun, Dec 25, 2016 at 10:08 AM, Mike Bonner <[hidden email]> wrote:
>
>> And on that note, heading to see the family.  Merry (insert your own
>> acceptable season greeting or general wish for happiness here.)
>>
>> On Sun, Dec 25, 2016 at 10:08 AM, Mike Bonner <[hidden email]> wrote:
>>
>>> Actually, the question boils down to "is the user active."  not "what key
>>> is pressed, was a screen scrolled(using what device) , or what button was
>>> clicked."  I could be wrong. /shrug  The only recent issue that needed to
>>> be solved is that scroll is an activity too, and there was no easy way to
>>> get lc to see that as an action.
>>>
>>> This ignores the whole question and lets lc poll the os to see if there
>>> was any HID action at all-- this (if I understand correctly)  being the
>>> ultimate goal.
>>> So yeah, if you scroll with you belkin, its a scroll.  As on a mighty
>>> mouse. But for this purpose (again, if I understand correctly)  it doesn't
>>> matter.  An action of any type, by a user (typing, scrolling, clicking,
>>> using a touch screen) shows that the user is actually sitting at the
>>> computer.
>>>
>>> If you have a different needs that just tracking idle/active time, this
>>> is not for you.
>>> Otherwise, there is no longer a need to look at keysdown() or
>>> mousescreenloc at all.  Just grab the number from the os. If the mouse has
>>> moved recently, it'll be small. Same for keypresses, scrolls, clicks,
>>> screen touches.
>>>
>>> So as in the example of catatonia.. Was it a poke, a tickle, a prod, a
>>> kick..  If all you're looking for is signs of brain activity, it doesn't
>>> matter.  (simplified of course, because in those cases examining responses
>>> to different stimuli DOES matter during evaluation.. but not so with the
>>> desired goal)
>>>
>>> On Sun, Dec 25, 2016 at 9:51 AM, Richmond Mathewson <
>>> [hidden email]> wrote:
>>>
>>>> Aha: thanks.
>>>>
>>>> On 12/25/16 6:39 pm, Mike Bonner wrote:
>>>>
>>>>> The script does an end run of the whole situation.  The os itself is
>>>>> keeping track of the idle time between user events.  All the script
>>>>> does is
>>>>> grab the current value. And since only HID (human interface devices) are
>>>>> tracked, any mouse/keyboard activity in any app of the system will reset
>>>>> the timer.  So technically no, the scroll won't "register" in the lc
>>>>> stack
>>>>> (meaning it won't cause a handler to fire), but the OS does track HID
>>>>> actions..  All the stack does is request the information from the os
>>>>> (in a
>>>>> loop), that information being the time since the last user activity.
>>>>>
>>>> So, the inevitable question is how one would use an idle time value to
>>>> tell
>>>> one that the end-user his performed a scroll (and whether up or down),
>>>> as all
>>>> those idle time values are are times in (?) micro-seconds.
>>>>
>>>> I assume (?) that, somewhere in the belly of the beast (Mac OS) a HID
>>>> performed action
>>>> must register as such, and also as WHICH HID was used, and WHAT action
>>>> was performed on
>>>> that HID.
>>>>
>>>> A forward scroll on my Belkin Nostromo is just as much a forward scroll
>>>> as one on my mighty mouse.
>>>>
>>>> The question that started this thread concerns NOT whether one can pick
>>>> up signals that HIDs are
>>>> being used, but when they ARE being used, which of the activities being
>>>> performed is a scroll.
>>>>
>>>> This seems remarkably like the problem with other people:
>>>>
>>>> 1. We can generally tell when brain activity is going on in other people
>>>> (however, c.f. catatonia),
>>>> and we can stick electrodes into parts of the human brain so that we can
>>>> pick up electric pulses
>>>> that tell us when the brain is receiving signals from outside the body.
>>>>
>>>> 2. What cannot (as far as I am aware) be worked out (if one is not
>>>> cheating and looking at who
>>>> is poking your volunteer in the stomach with a chopstick) is what is
>>>> being done to make the brain
>>>> register those signals.
>>>>
>>>> Richmond.
>>>>
>>>>
>>>>>
>>>>> On Sun, Dec 25, 2016 at 9:29 AM, Richmond Mathewson <
>>>>> [hidden email]> wrote:
>>>>>
>>>>> Does that mean that if, say, I have a stack running your script in the
>>>>>> stackScript
>>>>>> and I'm scrolling a window in Firefox that that scrolling will
>>>>>> register in
>>>>>> the LC stack?
>>>>>>
>>>>>> The reason I am asking that question is because I don't quite
>>>>>> understand
>>>>>> how one effect a mouseUp
>>>>>> while one is scrolling with one's mouse at the same time and the
>>>>>> mouseUp
>>>>>> not affecting the frontmost app.
>>>>>>
>>>>>> Richmond.
>>>>>>
>>>>>>
>>>>>> On 12/25/16 5:56 pm, Mike Bonner wrote:
>>>>>>
>>>>>> I have an answer..
>>>>>>> Heres a sample script:
>>>>>>> local sRunning
>>>>>>>
>>>>>>> on mouseUp
>>>>>>> if sRunning is empty then put false into sRunning
>>>>>>> put not sRunning into sRunning
>>>>>>> loopit
>>>>>>> end mouseUp
>>>>>>>
>>>>>>> command loopit
>>>>>>> if sRunning then
>>>>>>> put the last word of (shell("ioreg -c IOHIDSystem |grep Idle")) into
>>>>>>> tIdle
>>>>>>> put tIdle / 1000000000 into field 1
>>>>>>> send "loopit" to me in 2 sec
>>>>>>> end if
>>>>>>> end loopit
>>>>>>>
>>>>>>> The script is in a button, and I have a single field on the card.  The
>>>>>>> math
>>>>>>> is done to convert to seconds of idle.
>>>>>>>
>>>>>>> The are only 2 disclaimers here.  First is that the value returned pre
>>>>>>> 10.3
>>>>>>> is hex so you'd have to handle that if you have an earlier osx.  10.3
>>>>>>> and
>>>>>>> after this solution should work fine.
>>>>>>>
>>>>>>> The second issue is is that on mac 10.12, the idle time won't update
>>>>>>> on
>>>>>>> typing.  Its an osx issue for that specific version, but worst case
>>>>>>> you
>>>>>>> already have a method to track keypresses.
>>>>>>>
>>>>>>> On Sun, Dec 25, 2016 at 8:21 AM, Paul Dupuis <[hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On 12/25/2016 10:05 AM, Terry Vogelaar wrote:
>>>>>>>
>>>>>>>> So it starts to become clear that it might not be possible to do
>>>>>>>>> what I
>>>>>>>>>
>>>>>>>>> want. Although I hope to be wrong about that.
>>>>>>>> I think it is very unlikely you can do this in LC - without
>>>>>>>> externals or
>>>>>>>> LCB widgets from "infinite Livecode".
>>>>>>>>
>>>>>>>> The active mouse and keyboard drivers capture events from these
>>>>>>>> devices
>>>>>>>> and pass that information to the operating system, which massages the
>>>>>>>> data and passed a higher level of events on to the active
>>>>>>>> application,
>>>>>>>> which looks for such events and handles them. In the case of the
>>>>>>>> LiveCode engine - or any app built on the LC engine - that is
>>>>>>>> executing
>>>>>>>> applicable messages for your scripts to handle.
>>>>>>>>
>>>>>>>> Most productivity tracking software works by effectively inserting
>>>>>>>> code
>>>>>>>> into where the device drivers meet the operating system, so that
>>>>>>>> mouse
>>>>>>>> and keyboard events are captured by the productivity app's as well as
>>>>>>>> being sent by the OS to the active application as normal.
>>>>>>>>
>>>>>>>> Using LCB and LC9.0 you might be able to write an LCB widget that
>>>>>>>> does
>>>>>>>> this, but I am not familiar enough with current OSX APIs for event
>>>>>>>> capture or drivers under OSX to or the state of work in LC9.0 on
>>>>>>>> integrating OS API calls to say for sure.
>>>>>>>>
>>>>>>>> You are unlikely to be able to do what you want in LiveCode script
>>>>>>>> alone.
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>
>>>> _______________________________________________
>>>> 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: Detect scroll activity (when LC is not frontmost)

Richmond Mathewson-2
In reply to this post by Mike Bonner
And, likewise:

<https://www.facebook.com/#>

I hope everyone can find their moment of peace and tranquility, whatever
their views on religion.

Richmond.



On 12/25/16 7:19 pm, Mike Bonner wrote:

> Really headed next door now but..
> This is from the original poster..
> "I’m working on a productivity & RSI prevention app. So I want to notice
> activity while my project is not the frontmost application."
>
> On Sun, Dec 25, 2016 at 10:08 AM, Mike Bonner <[hidden email]> wrote:
>
>> And on that note, heading to see the family.  Merry (insert your own
>> acceptable season greeting or general wish for happiness here.)
>>
>> On Sun, Dec 25, 2016 at 10:08 AM, Mike Bonner <[hidden email]> wrote:
>>
>>> Actually, the question boils down to "is the user active."  not "what key
>>> is pressed, was a screen scrolled(using what device) , or what button was
>>> clicked."  I could be wrong. /shrug  The only recent issue that needed to
>>> be solved is that scroll is an activity too, and there was no easy way to
>>> get lc to see that as an action.
>>>
>>> This ignores the whole question and lets lc poll the os to see if there
>>> was any HID action at all-- this (if I understand correctly)  being the
>>> ultimate goal.
>>> So yeah, if you scroll with you belkin, its a scroll.  As on a mighty
>>> mouse. But for this purpose (again, if I understand correctly)  it doesn't
>>> matter.  An action of any type, by a user (typing, scrolling, clicking,
>>> using a touch screen) shows that the user is actually sitting at the
>>> computer.
>>>
>>> If you have a different needs that just tracking idle/active time, this
>>> is not for you.
>>> Otherwise, there is no longer a need to look at keysdown() or
>>> mousescreenloc at all.  Just grab the number from the os. If the mouse has
>>> moved recently, it'll be small. Same for keypresses, scrolls, clicks,
>>> screen touches.
>>>
>>> So as in the example of catatonia.. Was it a poke, a tickle, a prod, a
>>> kick..  If all you're looking for is signs of brain activity, it doesn't
>>> matter.  (simplified of course, because in those cases examining responses
>>> to different stimuli DOES matter during evaluation.. but not so with the
>>> desired goal)
>>>
>>> On Sun, Dec 25, 2016 at 9:51 AM, Richmond Mathewson <
>>> [hidden email]> wrote:
>>>
>>>> Aha: thanks.
>>>>
>>>> On 12/25/16 6:39 pm, Mike Bonner wrote:
>>>>
>>>>> The script does an end run of the whole situation.  The os itself is
>>>>> keeping track of the idle time between user events.  All the script
>>>>> does is
>>>>> grab the current value. And since only HID (human interface devices) are
>>>>> tracked, any mouse/keyboard activity in any app of the system will reset
>>>>> the timer.  So technically no, the scroll won't "register" in the lc
>>>>> stack
>>>>> (meaning it won't cause a handler to fire), but the OS does track HID
>>>>> actions..  All the stack does is request the information from the os
>>>>> (in a
>>>>> loop), that information being the time since the last user activity.
>>>>>
>>>> So, the inevitable question is how one would use an idle time value to
>>>> tell
>>>> one that the end-user his performed a scroll (and whether up or down),
>>>> as all
>>>> those idle time values are are times in (?) micro-seconds.
>>>>
>>>> I assume (?) that, somewhere in the belly of the beast (Mac OS) a HID
>>>> performed action
>>>> must register as such, and also as WHICH HID was used, and WHAT action
>>>> was performed on
>>>> that HID.
>>>>
>>>> A forward scroll on my Belkin Nostromo is just as much a forward scroll
>>>> as one on my mighty mouse.
>>>>
>>>> The question that started this thread concerns NOT whether one can pick
>>>> up signals that HIDs are
>>>> being used, but when they ARE being used, which of the activities being
>>>> performed is a scroll.
>>>>
>>>> This seems remarkably like the problem with other people:
>>>>
>>>> 1. We can generally tell when brain activity is going on in other people
>>>> (however, c.f. catatonia),
>>>> and we can stick electrodes into parts of the human brain so that we can
>>>> pick up electric pulses
>>>> that tell us when the brain is receiving signals from outside the body.
>>>>
>>>> 2. What cannot (as far as I am aware) be worked out (if one is not
>>>> cheating and looking at who
>>>> is poking your volunteer in the stomach with a chopstick) is what is
>>>> being done to make the brain
>>>> register those signals.
>>>>
>>>> Richmond.
>>>>
>>>>
>>>>>
>>>>> On Sun, Dec 25, 2016 at 9:29 AM, Richmond Mathewson <
>>>>> [hidden email]> wrote:
>>>>>
>>>>> Does that mean that if, say, I have a stack running your script in the
>>>>>> stackScript
>>>>>> and I'm scrolling a window in Firefox that that scrolling will
>>>>>> register in
>>>>>> the LC stack?
>>>>>>
>>>>>> The reason I am asking that question is because I don't quite
>>>>>> understand
>>>>>> how one effect a mouseUp
>>>>>> while one is scrolling with one's mouse at the same time and the
>>>>>> mouseUp
>>>>>> not affecting the frontmost app.
>>>>>>
>>>>>> Richmond.
>>>>>>
>>>>>>
>>>>>> On 12/25/16 5:56 pm, Mike Bonner wrote:
>>>>>>
>>>>>> I have an answer..
>>>>>>> Heres a sample script:
>>>>>>> local sRunning
>>>>>>>
>>>>>>> on mouseUp
>>>>>>> if sRunning is empty then put false into sRunning
>>>>>>> put not sRunning into sRunning
>>>>>>> loopit
>>>>>>> end mouseUp
>>>>>>>
>>>>>>> command loopit
>>>>>>> if sRunning then
>>>>>>> put the last word of (shell("ioreg -c IOHIDSystem |grep Idle")) into
>>>>>>> tIdle
>>>>>>> put tIdle / 1000000000 into field 1
>>>>>>> send "loopit" to me in 2 sec
>>>>>>> end if
>>>>>>> end loopit
>>>>>>>
>>>>>>> The script is in a button, and I have a single field on the card.  The
>>>>>>> math
>>>>>>> is done to convert to seconds of idle.
>>>>>>>
>>>>>>> The are only 2 disclaimers here.  First is that the value returned pre
>>>>>>> 10.3
>>>>>>> is hex so you'd have to handle that if you have an earlier osx.  10.3
>>>>>>> and
>>>>>>> after this solution should work fine.
>>>>>>>
>>>>>>> The second issue is is that on mac 10.12, the idle time won't update
>>>>>>> on
>>>>>>> typing.  Its an osx issue for that specific version, but worst case
>>>>>>> you
>>>>>>> already have a method to track keypresses.
>>>>>>>
>>>>>>> On Sun, Dec 25, 2016 at 8:21 AM, Paul Dupuis <[hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On 12/25/2016 10:05 AM, Terry Vogelaar wrote:
>>>>>>>
>>>>>>>> So it starts to become clear that it might not be possible to do
>>>>>>>>> what I
>>>>>>>>>
>>>>>>>>> want. Although I hope to be wrong about that.
>>>>>>>> I think it is very unlikely you can do this in LC - without
>>>>>>>> externals or
>>>>>>>> LCB widgets from "infinite Livecode".
>>>>>>>>
>>>>>>>> The active mouse and keyboard drivers capture events from these
>>>>>>>> devices
>>>>>>>> and pass that information to the operating system, which massages the
>>>>>>>> data and passed a higher level of events on to the active
>>>>>>>> application,
>>>>>>>> which looks for such events and handles them. In the case of the
>>>>>>>> LiveCode engine - or any app built on the LC engine - that is
>>>>>>>> executing
>>>>>>>> applicable messages for your scripts to handle.
>>>>>>>>
>>>>>>>> Most productivity tracking software works by effectively inserting
>>>>>>>> code
>>>>>>>> into where the device drivers meet the operating system, so that
>>>>>>>> mouse
>>>>>>>> and keyboard events are captured by the productivity app's as well as
>>>>>>>> being sent by the OS to the active application as normal.
>>>>>>>>
>>>>>>>> Using LCB and LC9.0 you might be able to write an LCB widget that
>>>>>>>> does
>>>>>>>> this, but I am not familiar enough with current OSX APIs for event
>>>>>>>> capture or drivers under OSX to or the state of work in LC9.0 on
>>>>>>>> integrating OS API calls to say for sure.
>>>>>>>>
>>>>>>>> You are unlikely to be able to do what you want in LiveCode script
>>>>>>>> alone.
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>
>>>> _______________________________________________
>>>> 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: Detect scroll activity (when LC is not frontmost)

Lagi Pittas
In reply to this post by Richmond Mathewson-2
Hi

AppleScript is the way to go with a shell execute command every x seconds or so

Found this to get you started

http://hints.macworld.com/article.php?story=20040330161158532

Lagi

Sent from my iPhone

> On 24 Dec 2016, at 19:39, Richmond Mathewson <[hidden email]> wrote:
>
> In a perfect world . . . .
>
> There would be a cross-platform solution that did not depend of external code snippets or components
> of operating systems.
>
> A little bird just sang "poll a key" in my ear, but I dismissed it as it made me think of the executioner
> on Tower Hill having to finally hack off the Duke of Monmouth's head with his pocket knife as his
> axe had gone blunt.
>
> Richmond.
>
>> On 12/24/16 7:41 pm, Mike Bonner wrote:
>> nvm, found the answer. Now going afk long enough to see if I can pick up an
>> "idle" msg"
>>
>>
>>> On Sat, Dec 24, 2016 at 10:24 AM, Mike Bonner <[hidden email]> wrote:
>>>
>>> While digging around for answers I came across something interesting..
>>>
>>> From windows vista and onward there is a program quser.exe located in
>>> \windows\system32 that returns the current user state. From the command
>>> line it shows
>>> mike                  console             1  Active      none   12/16/2016
>>> 5:56 PM
>>>
>>> I was going to test and see if it would show idle after a period of
>>> inactivity (using a looping lc shell call) but heres the interesting
>>> thing..  Lc can't see it.  At all.  Trying a shell call returns " is not
>>> recognized as an internal or external command, operable program, or batch
>>> file.
>>>
>>> I can change to the directory in shell and "dir" and there it is.  I can
>>> run it from shell.
>>>
>>> If I do a shell call shell("dir quser.exe") on that directory it says
>>> "Directory of c:\windows\system" file not found.
>>> If I get the files, it isn't there.
>>>
>>> So my question is this.. What the heck is going on?  Its not a hidden or
>>> system file, as far as I can tell its just a file sitting there like
>>> normal.  Why can't lc see it?  (why can't the LC shell see it for that
>>> matter)
>>>
>>> On Sat, Dec 24, 2016 at 9:49 AM, Richmond Mathewson <
>>> [hidden email]> wrote:
>>>
>>>> Sorry: late to the party!
>>>>
>>>> A rawKeyDown message IS recieved even IF the mouse is NOT in the LiveCode
>>>> window, BUT
>>>> the LiveCode window MUST be the front window.
>>>>
>>>> A rawKeyDown message won't be recieved IF the mouse is NOT in the
>>>> LiveCode windows if
>>>> it comes from a mouse button, scrollwheel or track ball.
>>>>
>>>> The micro trackball on the top of my Macintosh mouse sends these
>>>> rawKeydowns:
>>>>
>>>> Left: 65310 . . . . . . Left Arrow Key: 65361
>>>>
>>>> Right: 65311 . . . . . . Right Arrow Key: 65363
>>>>
>>>> Forward: 65308 . . . . . . Up Arrow Key: 65362
>>>>
>>>> Back: 65309 . . . . . .Down Arrow Key 65364
>>>>
>>>> Richmond.
>>>>
>>>>
>>>> _______________________________________________
>>>> 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: Detect scroll activity (when LC is not frontmost)

Terry Vogelaar
In reply to this post by Terry Vogelaar
Thank you, Mike, for this! This is what I was searching for indeed. And you're right; I want to detect activity, not just scrolling. Scrolling was the only activity I could not catch yet, hence the subject line. But this does exactly what I want.

Fortunately I can not replicate the issue with 10.12 with typing. I am on 10.12.2, so maybe it has already been fixed.

This is a priceless Christmas gift to me. Wow!


With kind regards,
Terry Vogelaar

> Op 25 dec. 2016, om 18:19 heeft [hidden email] het volgende geschreven:
>
> I have an answer..
>
> Heres a sample script:
> local sRunning
>
> on mouseUp
> if sRunning is empty then put false into sRunning
> put not sRunning into sRunning
> loopit
> end mouseUp
>
> command loopit
> if sRunning then
> put the last word of (shell("ioreg -c IOHIDSystem |grep Idle")) into tIdle
> put tIdle / 1000000000 into field 1
> send "loopit" to me in 2 sec
> end if
> end loopit
>
> The script is in a button, and I have a single field on the card.  The math
> is done to convert to seconds of idle.
>
> The are only 2 disclaimers here.  First is that the value returned pre 10.3
> is hex so you'd have to handle that if you have an earlier osx.  10.3 and
> after this solution should work fine.
>
> The second issue is is that on mac 10.12, the idle time won't update on
> typing.  Its an osx issue for that specific version, but worst case you
> already have a method to track keypresses.

_______________________________________________
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: Detect scroll activity (when LC is not frontmost)

Mike Bonner
If I remember what I read, yes it was only 10.12 so yeah, Its most likely
fixed by 10.12.2  Merry Christmas!

On Sun, Dec 25, 2016 at 10:25 PM, Terry Vogelaar <[hidden email]>
wrote:

> Thank you, Mike, for this! This is what I was searching for indeed. And
> you're right; I want to detect activity, not just scrolling. Scrolling was
> the only activity I could not catch yet, hence the subject line. But this
> does exactly what I want.
>
> Fortunately I can not replicate the issue with 10.12 with typing. I am on
> 10.12.2, so maybe it has already been fixed.
>
> This is a priceless Christmas gift to me. Wow!
>
>
> With kind regards,
> Terry Vogelaar
>
> > Op 25 dec. 2016, om 18:19 heeft [hidden email]
> het volgende geschreven:
> >
> > I have an answer..
> >
> > Heres a sample script:
> > local sRunning
> >
> > on mouseUp
> > if sRunning is empty then put false into sRunning
> > put not sRunning into sRunning
> > loopit
> > end mouseUp
> >
> > command loopit
> > if sRunning then
> > put the last word of (shell("ioreg -c IOHIDSystem |grep Idle")) into
> tIdle
> > put tIdle / 1000000000 into field 1
> > send "loopit" to me in 2 sec
> > end if
> > end loopit
> >
> > The script is in a button, and I have a single field on the card.  The
> math
> > is done to convert to seconds of idle.
> >
> > The are only 2 disclaimers here.  First is that the value returned pre
> 10.3
> > is hex so you'd have to handle that if you have an earlier osx.  10.3 and
> > after this solution should work fine.
> >
> > The second issue is is that on mac 10.12, the idle time won't update on
> > typing.  Its an osx issue for that specific version, but worst case you
> > already have a method to track keypresses.
>
> _______________________________________________
> 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: Detect scroll activity (when LC is not frontmost)

Bob Sneidar-2
In reply to this post by Paul Dupuis
If you were able to do this, LC might get flagged as malware. Software that attempts to modify the OS or drivers gets the attention of malware protection pretty quickly.

Bob S


On Dec 25, 2016, at 07:21 , Paul Dupuis <[hidden email]<mailto:[hidden email]>> wrote:

Most productivity tracking software works by effectively inserting code
into where the device drivers meet the operating system, so that mouse
and keyboard events are captured by the productivity app's as well as
being sent by the OS to the active application as normal.

Using LCB and LC9.0 you might be able to write an LCB widget that does
this, but I am not familiar enough with current OSX APIs for event
capture or drivers under OSX to or the state of work in LC9.0 on
integrating OS API calls to say for sure.

You are unlikely to be able to do what you want in LiveCode script alone.

_______________________________________________
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