SHIFTkey horrors

Richmond richmondmathewson at gmail.com
Wed May 9 09:25:34 EDT 2012


On 05/09/2012 04:13 PM, Mike Bonner wrote:
> Shouldn't be a big deal, in fact during the game academy a game loop
> (interesting code by the way) was used that did all kinds of things at
> approximately 50fps with enough time to animate, accept keypresses and
> mouse events etc. Think the stack code can be found in the forums somewhere
> if you want to look at it. It worked really well.
>
> In your case since its going to be pretty much
> is shiftkeydown
> check a property to see if it was already down
> if not, change keyboard and set state property, otherwise do nothing
> correct keyboard already showing
> if shiftkey is up
> check property to see if it was already up
> if not, change keyboard and set state property, otherwise do nothing the
> correct keyboard is already showing
>
>
> If coded right most of the loops will execute 2 if checks (sure it could be
> done other ways) The only time any more code would run is on a shiftkey
> state change.
>
> Of course I don't know if "if shifkey() is down and the shiftkeystate of
> this stack is not "down" then." is faster than 2 separate ifs but suspect
> its 6 of 1 half dozen of the other.
>

My main problem is that one CANNOT do this sort of thing:

on shiftKeyDown

and, while it is really very easy indeed to check if the user has the 
SHIFTkey pressed at the same time as they have another key that 
generates a RawKeyDown signal pressed, what I need to do is to catch the 
shiftKey being pressed and at that time perform a state
change.

what CANNOT be down is catch the SHIFTkey being pressed when it is 
pressed by itself.

polling the shiftkey() seems cumbersome.

>
>
>
>
>> That sounds a good idea.
>>
>> BUT isn't the 'send' going to slow things down with regard to other
>> keystrokes?
>>
>>
>>> On Wed, May 9, 2012 at 6:43 AM, Richmond <richmondmathewson at gmail.com>**
>>> wrote:
>>>
>>>   What follows is an extract from a message I have just sent to a
>>>> colleague;
>>>> it concerns
>>>> a really large problem:
>>>>
>>>> ------------------------------****----------------------------**--**
>>>> ------------------------------****-----------------------
>>>>
>>>>
>>>> "Then when the shift key is held down, all the vowels appear, type your
>>>> vowel,
>>>> then when you let go, the consonant panel appears again
>>>> This behavior will be *very* familiar to everyone..."
>>>>
>>>> That would be perfectly alright (and it appeals to me) if it were not for
>>>> a limitation in Livecode and/or Macintosh; that when one presses
>>>> the SHIFT key on a Mac keyboard a Livecode stack does not receive a
>>>> rawKeyDown signal: this has also been discussed between us
>>>> several times.
>>>>
>>>> For instance; one could have a very simple bit of code rather like this:
>>>>
>>>> if shiftkey() is down then
>>>>   --do something--
>>>> else
>>>>   --do something else--
>>>> end if
>>>>
>>>> and it would work without a hitch.
>>>>
>>>> What one CANNOT do is something like this:
>>>>
>>>> on rawKeyDown KEE
>>>>   if KEE= XXXX  then --where 'XXXX' is a number--
>>>>     ---do something----
>>>>   else
>>>>     ---do something else---
>>>>   end if
>>>> end rawKeyDown
>>>>
>>>> as pressing the SHIFTkey on a Mac keyboard does not generate a rawKeyDown
>>>> number
>>>> rather like the DELETEkey generates 65288
>>>>
>>>> this has been a "right bu**er" all along.
>>>>
>>>> SO; it is perfectly possible to have a KEY on the keyboard generate a
>>>> consonant when the SHIFTkey is NOT down,
>>>> and a vowel when the SHIFTkey is down; but one cannot change the display
>>>> that the typist sees in front of him on the screen.
>>>>
>>>> [come to think of things, I'm going to post this bit 'up' on the Use-List
>>>> on the off-chance that some wise soul has
>>>> found a work-around for this old chestnut]
>>>>
>>>> Please don't think I'm so daft I haven't thought about this "one" long
>>>> and
>>>> hard . . .  :)
>>>>
>>>> ------------------------------****----------------------------**--**
>>>>
>>>> -----------------
>>>>
>>>> does anybody have any suggestions as to how one might circumvent this
>>>> problem?
>>>>
>>>> sincerely, Richmond.
>>>>
>>>> ______________________________****_________________
>>>>
>>>> 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>
>>>> <**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<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<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






More information about the Use-livecode mailing list