In the past when ever I wanted to provide for alternate actions to
be run from the same basic event, such as a button-click, I would set my
form's Key Preview to True and then set Key Down and Key Up events for the
Shift and/or Ctrl keys which would alter a Boolean var's value. The Shift
Key down would set a var named "ShftDwn" to true and the Shift key Up would
set it back to its default state of False.
In the event method called by the button-click I would use an
if...then...else block to check the current value of the "ShftDwn" variable
and depending upon that value would branch the methods code accordingly.
This worked fine except that I found many cases where the
button-click's action resulted in calls to other units/forms and
necessitated the use of a global variable to hold the key state value. ( I
no longer argue the case for global variables because experience finally
showed me the error of my ways! <g> Not that I didn't believe you guys...but
I had to justify what I was told in actual experience! )
So next I tried using another approach suggested by someone here:
"if GetAsyncKeyState(VK_SHIFT) = 0 then begin end else begin end;", and
though this solved some of the problems it also introduced new ones!
As an example, in a current project I have a button-click action
that when called, dynamically creates and then shows modally a specialty
form. The user may then select and open a non-modal form from a list of
entries in the first, modal form. When the user has finished he or she may
close the two open forms in reverse order or simply close the modal form
which will make sure it's child, non-modal form is closed first.
In the modal form's list of entries, of which there can be any
number, just one may be set as the default choice. The one the user is most
likely to want to work with. And so I wanted to add a shift key down with
the button-click that would simply bypass the modal form and directly open
the non-modal form as if the user had actually selected that item from the
list.
Using "GetAsyncKeyState(VK_SHIFT)" won't work in this case as I
proved by setting breakpoints in my code to see if the correct code branch
was being followed depending upon the combined button-click and Shift key
down state. This is evidently because letting the shift key back up after
the button-click has finished returns it to a normal state value of "0" I
assumed, however I found that even if I held the Shift key down through the
entire block of code as it runs, the branch of code I wanted to run was
never taken! I haven't tried tracing the shift key's state value while
using this method, but I will tomorrow. In the meantime I'm assuming that
this method acts like a trigger, setting the Key State to 1 and then
immediately back to 0 again...and is not dependant upon the shift key being
released!
So once again I was forced to revert back to my old method of using
a global Boolean variable and Key Preview. Only in order to allow for those
whose fingers move faster than their brains, I've removed the OnKeyUp event,
and merely reset the variable back to its default state of False at the end
of the code block that is called by the original button-click. This block
of code is actually within the non-modal forms unit so I am forced to use a
global variable for this, otherwise I'd have to duplicate this quite large
block of code within the button-click method as well.
In any case it seems to me that there should be a better way of
handling this and situations like it. Especially those where the initial
event with or without the key down added calls a chain of commands/methods
in one or more different forms from the once handling the original
button-click! I'd appreciate any thoughts on the topic.
from Robert Meek dba Tangentals Design CCopyright 2006
"When I examine myself and my methods of thought, I come to the conclusion
that the gift of Fantasy has meant more to me then my talent for absorbing
positive knowledge!"
Albert Einstein
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi