VFP : .keypreview and .keypress()
Gene Wirchenko
would otherwise go to the input controls. I have set .keypreview to
t. in the form. The return values aren't what I expect though.
What's going on?
The docs say that when the keystroke contains <Alt>, no value is
returned. Fine. That does happen. Unfortunately, it can also happen
when <Ctrl> is involved, but only some keys. Which ones? Can I
override this or am I stuck with the behaviour? (For example,
<Ctrl-A> insists on being <select all text>. it would make a great
<Add Record>.)
I would like to know what I can do with the keystrokes. I was
hoping to be able to modify a keystroke before passing it to the
control. For example, if I wanted every alphabetic character to be
capped before passing it to the current control, how would I do it in
the form's .keypress()? (Yes, I could just modify every control
accordingly, but I'd prefer to have the unusual behaviours in the form
only as I'm trying to keep the oddities within the griddish class.)
What exactly do dodefault() and nodefault mean inside of the
form's .keypress()?
Is there anything else that I'm likely to stumble into while
playing in this area?
Code samples and pointers are welcome.
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Peter Frano
I just tried a simple use of KeyPress / KeyPreview and this is what I
suggest:
Any SYSMENU shortcut takes precedence - you cannot use them unles you issue
SET SYSM TO or release the menu pad containing the shortcut from sysmenu.
To modify the keystroke you have to "hide" it from further processing
(NODEFAULT) and provide a new one. The KeyPress event could look like this:
LPARAMETERS nKeyCode, nShiftAltCtrl
LOCAL cKey
cKey = CHR(nKeyCode)
IF nShiftAltCtrl=0 AND ISLOWER(cKey) && it is a lowercase character
KEYB UPPER(cKey) && send uppercase instead
NODEFA && stop processing the lowercase character
ENDIF
IF nShiftAltCtrl=2 AND nKeyCode=146 && CTRL+Insert for new record
APPEND BLANK
ENDIF
HTH
Peter
Gene Wirchenko <ge...@shuswap.net> wrote in message
news:38f27bcf...@news.shuswap.net...
Duane Walker
----- Original Message -----
From: Gene Wirchenko <ge...@shuswap.net>
Newsgroups:
comp.databases.xbase.fox,microsoft.public.fox.programmer.exchange
Sent: Monday, April 10, 2000 7:12 PM
Subject: VFP : .keypreview and .keypress()
> For my griddish control, I need to intercept keystrokes that
> would otherwise go to the input controls. I have set .keypreview to
> t. in the form. The return values aren't what I expect though.
> What's going on?
>
> The docs say that when the keystroke contains <Alt>, no value is
> returned. Fine. That does happen. Unfortunately, it can also happen
> when <Ctrl> is involved, but only some keys. Which ones?
I have never found a list. I find them by trial and error.
>Can I override this or am I stuck with the behaviour? (For example,
> <Ctrl-A> insists on being <select all text>. it would make a great
> <Add Record>.)
I use a combination of ON KEY and the keypress to force behaviour the way my
client desires even if Windows doesn't want me too, For example F10 is
reservered by windows and does not get sent to the keypress method.
Therefore in my startup program i use the following On Key statement
On Key label F10 keyboard {SHIFT+F10}
Then i intercept the shift f10 in the keypress method. On keys overide all
keyboard behaviour. For your particular CTRL+A problem
on key label CTRL+A keyboard '{CTRL+SHIFT+Q}'
Then in the keypress code trap (nkeycode=17 and nshiftaltctrl=3). Just
remember to put your onkey assignments back when you exit.
Note i use the onkeys along with the keypress rather than on keys alone
because the ON key commands are harder to program with. They operate at the
sytem level, so you can not use the " thisform" object to reference methods
or properties. Therefore i only use the on key command to override the
reserved keystrokes
>
> I would like to know what I can do with the keystrokes. I was
> hoping to be able to modify a keystroke before passing it to the
> control. For example, if I wanted every alphabetic character to be
> capped before passing it to the current control, how would I do it in
> the form's .keypress()? (Yes, I could just modify every control
> accordingly, but I'd prefer to have the unusual behaviours in the form
> only as I'm trying to keep the oddities within the griddish class.)
One way you could do this is shown below;
case between(nkeycode,97,122) and nshiftaltctrl=0
nodefault
keyboard(chr(nkeycode-32))
IMHO, i would use the lostfocus of the control
>
> What exactly do dodefault() and nodefault mean inside of the
> form's .keypress()?
>
You must issue a nodefault command if you do not want the default behaviour
to occur in the keypress. FOr example is you want to open a search form
when you press "s" in an read only grid, if you don;t have the nodefault,
it will try to enter the "s" in the control giving an error message. If you
use nodefault you will prevent that When you use the dodefault command in
keypress, you have to give the parameters
case Something
dodefault(nkeycode,nshiftaltctrl)
> Is there anything else that I'm likely to stumble into while
> playing in this area?
I am sure you will, let us know when you do :)
>
> Code samples and pointers are welcome.
>
> Sincerely,
>
> Gene Wirchenko
>
> Computerese Irregular Verb Conjugation:
> I have preferences.
> You have biases.
> He/She has prejudices.
Hope this helps
Duane Walker
William Fields
F10 keys in the keypress event evaluate to negative numbers.
--
William Fields
MCP - Microsoft Visual FoxPro
US Bankruptcy Court
Phoenix, AZ
"Peter Frano" <fr...@nic.utc.sk> wrote in message
news:95546109...@cdwork.cvt.stuba.sk...
>
> I just tried a simple use of KeyPress / KeyPreview and this is what I
> suggest:
>
> Any SYSMENU shortcut takes precedence - you cannot use them unles you
issue
> SET SYSM TO or release the menu pad containing the shortcut from sysmenu.
>
> To modify the keystroke you have to "hide" it from further processing
> (NODEFAULT) and provide a new one. The KeyPress event could look like
this:
>
> LPARAMETERS nKeyCode, nShiftAltCtrl
>
> LOCAL cKey
> cKey = CHR(nKeyCode)
>
> IF nShiftAltCtrl=0 AND ISLOWER(cKey) && it is a lowercase character
> KEYB UPPER(cKey) && send uppercase instead
> NODEFA && stop processing the lowercase character
> ENDIF
>
> IF nShiftAltCtrl=2 AND nKeyCode=146 && CTRL+Insert for new record
> APPEND BLANK
> ENDIF
>
>
> HTH
> Peter
>
>
Gene Wirchenko
>From: Gene Wirchenko <ge...@shuswap.net>
[snip]
>> What exactly do dodefault() and nodefault mean inside of the
>> form's .keypress()?
>>
>You must issue a nodefault command if you do not want the default behaviour
>to occur in the keypress. FOr example is you want to open a search form
>when you press "s" in an read only grid, if you don;t have the nodefault,
>it will try to enter the "s" in the control giving an error message. If you
>use nodefault you will prevent that When you use the dodefault command in
>keypress, you have to give the parameters
>
>case Something
> dodefault(nkeycode,nshiftaltctrl)
The problem that I have is that I'm not sure of the event firing
sequence. I've tried passing a modified keystroke to the input
control (simple example: capitalize alphabetics), by calling the input
control's .keypress() but this doesn't do it. I have tried various
combination of dodefault and nodefault to no avail. I have seen the
situations of the keystroke is ignored, lower case keystrokes are
ignored, or the original case shows up. (By "ignored", I mean that
nothing shows on the input control. The form's .keypress() does see
the original keystroke.)
[snip]
Markus Voellmy
I got to that problem too, when trying to solve someones probs here
in the newsgroups. AFAIK know till know it only strikes you with
VFP6 (not 5).Perhaps even first after installing SP3, but I can't
verify this actually.
Clearing out the Sysmenu-HotKeys alone will not do the trick,
because disabling the menu seems only to stop the function, the
KeyPress event didn't get the Keystroke although, at least with
CTRL-C (That was the other guy's prob).
I found a quite "ugly" workaround but it doesn't please me.
You can set somewhere in the Init-Code of the form or the object
(what I would prefer ) all the needed ON KEY LABELS
(I don't know them yet) to call your own Keypress-routine,
but you'll get messed up with the object-hierarchy (if done in Object).
Though you can't use the THIS-Pointer outside of method code
I didn't yet find a way to make it real generic to use it in a forms
object. But for the form itself it should work.
Such a call would look like eg
ON KEY LABEL DO CTRL+C _Screen.ActiveForm.Keypress( 2, 3 )
In the KeypressEvent:
PARAMETERS nKeyCode, nShiftCtrlAlt
NODEFAULT && First STOP any "normal"
Keyhandling
DO CASE
CASE nKeyCode = 2 AND nShiftCtrlAlt = 3 && CTRL-C
DO myCopyRoutine
CASE nKeyCode ..... && B
A U (business as usual) <g>
...
OTHERWISE
DODEFAULT( nKeyCode, nShiftCtrlAlt ) && The Parameters are
crucial!
ENDCASE &&
or it won't happen anything
ENDPROC
HTH (somewhat)
Regards Markus
Gene Wirchenko <ge...@shuswap.net> schrieb in im Newsbeitrag:
38f27bcf...@news.shuswap.net...
> For my griddish control, I need to intercept keystrokes that
> would otherwise go to the input controls. I have set .keypreview to
> t. in the form. The return values aren't what I expect though.
> What's going on?
>
> The docs say that when the keystroke contains <Alt>, no value is
> returned. Fine. That does happen. Unfortunately, it can also happen
> when <Ctrl> is involved, but only some keys. Which ones? Can I
> override this or am I stuck with the behaviour? (For example,
> <Ctrl-A> insists on being <select all text>. it would make a great
> <Add Record>.)
>
> I would like to know what I can do with the keystrokes. I was
> hoping to be able to modify a keystroke before passing it to the
> control. For example, if I wanted every alphabetic character to be
> capped before passing it to the current control, how would I do it in
> the form's .keypress()? (Yes, I could just modify every control
> accordingly, but I'd prefer to have the unusual behaviours in the form
> only as I'm trying to keep the oddities within the griddish class.)
>
> What exactly do dodefault() and nodefault mean inside of the
> form's .keypress()?
>
> Is there anything else that I'm likely to stumble into while
> playing in this area?
>
> Code samples and pointers are welcome.
>
Duane Walker
> [snip]
>
> >> What exactly do dodefault() and nodefault mean inside of the
> >> form's .keypress()?
> >>
> >You must issue a nodefault command if you do not want the default
behaviour
> >to occur in the keypress. FOr example is you want to open a search form
> >when you press "s" in an read only grid, if you don;t have the
nodefault,
> >it will try to enter the "s" in the control giving an error message. If
you
> >use nodefault you will prevent that When you use the dodefault command
in
> >keypress, you have to give the parameters
> >
> >case Something
> > dodefault(nkeycode,nshiftaltctrl)
>
> sequence. I've tried passing a modified keystroke to the input
> control (simple example: capitalize alphabetics), by calling the input
> control's .keypress() but this doesn't do it. I have tried various
> combination of dodefault and nodefault to no avail. I have seen the
> situations of the keystroke is ignored, lower case keystrokes are
> ignored, or the original case shows up. (By "ignored", I mean that
> nothing shows on the input control. The form's .keypress() does see
> the original keystroke.)
>
If keypress is set to true, it intercepts the keystrokes first and then if
a nodefault is not found, it sends the keystroke to the active control is
well, In the following code your lowercase character would be entered in
the control and then the uppercase equiv would be sent.
**** Form keypress****
LPARAMETERS nKeyCode, nShiftAltCtrl
do case
case between(nkeycode,97,122) and nshiftaltctrl=0 && lowercase
keyboard chr(nkeycode-32) && make uppercase
endcase
****
By changing the code as follows, only the uppercase letter would be entered
**** Form keypress****
LPARAMETERS nKeyCode, nShiftAltCtrl
do case
case between(nkeycode,97,122) and nshiftaltctrl=0 && lowercase
nodefault
keyboard chr(nkeycode-32) && make uppercase
endcase
****
Another thing to watch for is the otherwise command in your case statements.
Make sure that all keys that you want handled by the control are not
addressed in the form's keypress.
Now this particular example could have just as easily been entered in the
control's keypress, however if you wanted to add navigation keys or if you
wanted this behaviour in all controls, it would be better suited in the
form's keypress.
I use a main form class that has all the navigation keys built into the
form's keypress and then create any new forms as a subclass of that.
Duane
Gene Wirchenko
[snip]
>**** Form keypress****
>
>LPARAMETERS nKeyCode, nShiftAltCtrl
>
>do case
> case between(nkeycode,97,122) and nshiftaltctrl=0 && lowercase
> nodefault
> keyboard chr(nkeycode-32) && make uppercase
> endcase
>****
>
>Another thing to watch for is the otherwise command in your case statements.
>Make sure that all keys that you want handled by the control are not
>addressed in the form's keypress.
>
>Now this particular example could have just as easily been entered in the
>control's keypress, however if you wanted to add navigation keys or if you
>wanted this behaviour in all controls, it would be better suited in the
>form's keypress.
Yes, my example was deliberately simple so that I could verify
correctness. Navigation key handling *is* what I want to do.
>I use a main form class that has all the navigation keys built into the
>form's keypress and then create any new forms as a subclass of that.
Could you please E-mail me that navigation keys code? Figuring
it all out for myself, I can do, but it's so slow. This will be a
central part of my class. Your help is the closest so far to what I
need. The documentation is rather weak and I'm not seeing too much in
the line of responses.
AFAICS, keystrokes fall into three categories: 1) ones that the
form should handle, 2) ones that the control should handle, and 3)
ones that should be eaten (nodefault and no other processing).
Category 3 is the nasty bunch. I don't want to have keystrokes that
when processed by the control cause unexpected effects.
Markus Voellmy
Just in case you haven't got them yet , check INKEY() in the online help,
there is all you need.
Regards Markus
Gene Wirchenko <ge...@shuswap.net> schrieb in im Newsbeitrag:
38f39c2e...@news.shuswap.net...
> "Duane Walker" <duane-...@home.com> wrote:
>
> [snip]
>
> >I use a main form class that has all the navigation keys built into the
> >form's keypress and then create any new forms as a subclass of that.
>
> Could you please E-mail me that navigation keys code? Figuring
> it all out for myself, I can do, but it's so slow. This will be a
> central part of my class. Your help is the closest so far to what I
> need. The documentation is rather weak and I'm not seeing too much in
> the line of responses.
>
> AFAICS, keystrokes fall into three categories: 1) ones that the
> form should handle, 2) ones that the control should handle, and 3)
> ones that should be eaten (nodefault and no other processing).
> Category 3 is the nasty bunch. I don't want to have keystrokes that
> when processed by the control cause unexpected effects.
>
Gene Wirchenko
>Just in case you haven't got them yet , check INKEY() in the online help,
>there is all you need.
I already had, but thanks. I've also found "reserved key
combinations" in the VFP 6 On-Line Docs.
Sincerelyl,