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 <richmondmathew...@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@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@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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
