Keypress and keypreview

[vgulielmus]

I quote from the help:

The KeyPress event does not occur for any combination of keys with the ALT key.

The object with the focus receives the KeyPress event.

A form can receive the KeyPress event in three special cases:
- The form contains no controls, or none of its controls is visible and enabled.
- The form's KeyPreview property is set to True (.T.). The form first receives the KeyPress event, and then the control with focus receives the event.
- The control on the form cannot process a keystroke, for example, when TAB is pressed to move the focus to the next control.

Try my sample posted below.

1) First of all, no control receive combination of keys with the ALT key, but the form do, so that kind of combinations can be processed, but directly in the form's keypress event.
2) Even when KeyPreview=.F., some keys are processed by the form's keypress event, although they are catched in the control's keypress event.

PUBLIC oFrm
oFrm=CREATEOBJECT("MyForm")
oFrm.show()

DEFINE CLASS MyForm as Form

KeyPreview=.F.
ADD OBJECT txt1 as TextBox WITH width=200
ADD OBJECT cmd as CommandButton WITH top=40,Caption="\<Click"
ADD OBJECT lst as ListBox WITH left=220
PROCEDURE txt1.KeyPress

LPARAMETERS nKey,nShift
MESSAGEBOX(This.name,0,STR(nKey)+STR(nShift))​

ENDPROC
PROCEDURE cmd.KeyPress

LPARAMETERS nKey,nShift
MESSAGEBOX(This.name,0,STR(nKey)+STR(nShift))​

ENDPROC
PROCEDURE lst.KeyPress

LPARAMETERS nKey,nShift
MESSAGEBOX(This.name,0,STR(nKey)+STR(nShift))​

ENDPROC
PROCEDURE KeyPress

LPARAMETERS nKey,nShift
MESSAGEBOX('Foxus changed or the current control cannot process the keystroke',0,STR(nKey)+STR(nShift))
* Not catched:
* Textbox
* - Printable keys + left, right, home, end
* - left arrow at the beginning (change focus to the previous control)
* - right arrow at the end (change focus to the next control)
* - Home two times (first jumps to the beggining, second change the focus to the previous control)
* - End two times (first jumps to the end, second change the focus to the next control)
* Command button
* - Hot key, space, Enter, CTRL+Enter
* Listbox
* - Printable keys + up, down, home, end, pgup, pgdown​

ENDPROC
PROCEDURE Init

RAND(-1)
This.lst.AddItem("First item")
This.lst.AddItem("Second item")
This.lst.AddItem("Third item")​

ENDPROC​

ENDDEFINE

 

[Olaf Doschke]

I have never seen anything of this as a limitation and never needed it in all my development life.

In regard of key processing you can do a global keyboard hook with BINDEVENTS. See

http://www.sweetpotatosoftware.com/spsblog/2005/08/07/BindEventOnSteroids.aspx

the GLOBAL KEYBOARD HOOK example.

In regard of sending keys to controls, I'd rather prefer triggering directly, what the keys should trigger. You can make use of selstart and .sellength, eg set .value. Sending focus back or forward, you can do that explicitly with setfocus. Anyway, to develop in a way, you can easily do automation tests yourself, is more valuable than automating the usage of forms with keyboard and mouse macros. If any interaction always triggers your business logic, an automation test can simply trigger that logic directly. If you want an interface test, user acceptance is more important and involves subjective thoughts on the ui, you can't put that in code at all.

Tools to suggest are FoxRunner and FoxUnit.

For anything else, eg programmatically picking an item in a listbox, I find it easier to trigger that from the inside, eg seeking the record you want picked and refresh the listbox/combobox.

Bye, Olaf.

 

[vgulielmus]

Tanks for the link. I believe this reply is more related to my previous thread
I'm not talking about limitations or bugs, but of more capabilities.
In the help is written that ALT+keys can't be intercepted, but I showed that they are, but in the form's, not in the objects keypress event.
In the help is written that the navigational keys like TAB is not processed by the object, but only by the form. But the things are more nuanced. For instance, TAB triggers the object's and the form's keypress, while HOME triggers only the object's keypress, although pressing HOME twice, change the focus to the previous object.


Vilhelm-Ion Praisach

 

[Olaf Doschke]

I was reacting to your comments:
> 1) First of all, no control receive combination of keys with the ALT key, but the form do, so that kind of combinations can be processed, but directly in the form's keypress event.
> 2) Even when KeyPreview=.F., some keys are processed by the form's keypress event, although they are catched in the control's keypress event.

This suggests you want to react to more keys than VFP documentation says you can process. I'd rather not use your workaround but a more native in the system approach of binding to keyboard events.

What you show may be an advantage in using keypress, but I'd not prefer it your way, as you describe yourself how complicated things are handled partly in the object and partly in the form. With Craigs fll you can bind to any keyboard event send to the application, you may even bind to all keyboard events overall, as a keylogger does, with good or bad deeds.

Bye, Olaf.

 

[vgulielmus]

I agree with that.
> With Craigs fll you can bind to any keyboard event send to the application, you may even bind to all keyboard events overall, as a keylogger does, with good or bad deeds.
Thanks again for your honest oppinions.


My respects,
Vilhelm-Ion Praisach

 

[Olaf Doschke]

Well,

I don't want to discourage you. Overall your code provides a solution to someone wanting to send keys to a certain textbox, for example.
That's beyond Craigs FLL, but you could post that as "Helpful Tip" rather than as a question.

Bye, Olaf.