altkey() down, up & halfway down

[Paul Hibbert]

I remembered something about updateScreen on the Game Academy, they used dispatch to poll the stack for a screen refresh and it didn't seem to have too much detrimental effect on the game, I had a quick look, took out the bones and tried this…

on preOpenStack
   if the platform is "MacOS" then dispatchUpdateKey
end preOpenStack

on altKeyCheck
    if altKey() = down then
      set the label of btn "clearButton" to "Reset"
   else
      set the label of btn "clearButton" to "Clear"
    end if
end altKeyCheck

on dispatchUpdateKey
   dispatch "altKeyCheck" to me
   send "dispatchUpdateKey" to me in 250 milliseconds ## Change the value to suit
end dispatchUpdateKey

It seems to work OK for my test, this would poll about 4 times a second so that shouldn't carry too much overhead, but is easily adjustable to suit your needs and you could easily add in a ctrlKey, cmdKey and shiftKey check too if necessary.

Just a thought.

Paul
 
On 2012-12-02, at 9:23 AM, Richmond wrote:

> On 12/02/2012 07:02 PM, Mike Bonner wrote:
>> Yeah, too true.  And if others are like me, having to wait for things to
>> catch up is really annoying!
>> 
>> Well, this is only osx (objective c) and I'm clueless about it, but the
>> example on this page might give someone who isn't a clueless c nub like me
>> a chance to build an external to catch key presses.
>> http://stackoverflow.com/questions/12113795/is-there-a-keyup-method-for-flagschanged
>> 
> 
> Ha, Ha; there is "only one problem" here; I haven't looked at any programming language (except for a brief 'perversion' with Toolbook)
> other than xTalk (or whatever Runtime Revolution call the Livecode langaue at the moment) since I left BBC BASIC in 1990.
> 
> So that code looks:
> 
> 1. odd
> 
> and
> 
> 2. I wouldn't have a clue how to integrate those few lines into anything else, let alone get it to interact with a Livecode standalone.
> 
> AND . . . and here's the rub . . .
> 
> I really want to have one code-base for my product, rather than fork the thing into 2 or 3 branches (Mac, Lin and Win),
> as subsequent modifications would involve a considerably large amount of (repetitive) work than keeping it as a single
> code base.
> 
> It is, of course, quite possible to have the stack to detect the operating system and act accordingly . . .
> 
>> 
>> On Sun, Dec 2, 2012 at 9:39 AM, Richmond <richmondmathewson at gmail.com>wrote:
>> 
>>> On 12/02/2012 05:58 PM, Mike Bonner wrote:
>>> 
>>>> Use idle as scott said? Or, if you don't need it to be super responsive.
>>>> 
>>> My Devawriter does have to be 'super responsive' as it is, ultimately, a
>>> glorified typewriter,
>>> and as such should, in an ideal situation, work not much more slowly than
>>> the speed one might enter
>>> text into a text editor. For the sake of argument, even though I type with
>>> only 2 fingers and have to
>>> keep looking at the keyboard, I still manage to knock out about 50 words a
>>> minute!
>>> 
>>> Obviously there isn't all that much 'idle' when someone is bashing away on
>>> the keyboard.
>>> 
>>> 
>>>  IE
>>>> you're using visual cues as andre suggested, then polling every 100 or 150
>>>> milliseconds might suffice. Idle is probably easiest. Was wondering about
>>>> the external, seems that since this is related to os/arch even an external
>>>> would just have to sit there polling also. (though it could do it in it's
>>>> own little area and only speak up when a key changes state)  So an
>>>> external
>>>> would probably be the best option except for that whole "having to write
>>>> it" thing.
>>>> 
>>>> 
>>>> 
>>> ______________________________**_________________
>>> use-livecode mailing list
>>> use-livecode at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>> http://lists.runrev.com/**mailman/listinfo/use-livecode<http://lists.runrev.com/mailman/listinfo/use-livecode>
>>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode