KeyPress method and nKeyCode = 22 3

[Eugen Fintina]

Hello, my friends!

I need to fire an action when user press "INS" key. I added the following code in KeyPress method of my form, but I got a strange behauvier. What's wrong in code?

Do Case
	Case nKeyCode = 22  [b][COLOR=#A40000]&& NOTHING HAPPENED[/color][/b]
		Wait Window '"INS" key was pressed!'
	Case nKeyCode = 162 [b][COLOR=#4E9A06]&& ALL IT'S OK[/color][/b]
		Wait Window '"ALT + INS" key was pressed!'
Endcase

Best regards,
Eugen

 

[Mike Lewis]

It's working OK for me, both for INS by itself and Alt+INS. There must be something somewhere in your form that is preventing it, but I can't think what it is.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Form.keypress only runs with form.keypreview = .t.
When you leave it at the default .f.only keypress of the individual controls happen, and then you see nothing at the form level.

Bye, Olaf.

 

[Eugen Fintina]

Hello, Olaf!

If I set form.keypreview = .T. I have the following behavior:

Do Case
	Case nKeyCode = 22  [b][COLOR=#4E9A06]&& ALL IT'S OK[/color][/b] 
		Wait Window '"INS" key was pressed!'
	Case nKeyCode = 162 [b][COLOR=#A40000]&& NOTHING HAPPENED[/color][/b]
		Wait Window '"ALT + INS" key was pressed!'
Endcase

Actually, it seems that I got reverse behavior. I am afraid that I don't understand the logic...

All the best,
Eugen

 

[Mike Lewis]

Eugen, this is still not what I am seeing. KeyPreview only causes the form to intercept the keystroke before the control. It does not change which keys are trapped or what codes they return. You said that your code is in the form's KeyPress, so KeyPreview shouldn't have any effect.

I still think there is something else in your form that is causing this problem. Why don't you create a new form, with no controls except perhaps a single textbox, and no other code. Put your code in the form's KeyPress, and see what happens.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Eugen Fintina]

Hello, Mike!

1. If I create a new form with NO CONTROLS and put the code in the form's KeyPress, all it's OK.
2. If I create a new form with SINGLE TEXTBOX CONTROL and put the code in the form's KeyPress, I've got the behavior that I described.

Eugen

 

[Mike Lewis]

Eugen,

OK. That explains it.

When you have a textbox on the form, and the form's KeyPreview is .F., then it is the textbox that processes the key. That's got nothing to do with the Keypress. It's the normal way things work.

The trouble is the INS key has a special meaning in a textbox. It toggles the insert/overwrite characteristic. If the texbox has focus, and you hit INS, then move the cursor back, then to type some new characters, the new characters overwrite the old ones. Hit INS again, and that behaviour is switched off. Clearly, this is by design. That's why you are not trapping INS when the texbox has focus.

When there is no textbox on the form, or when the form's KeyPreview is .T., it is the form that is trapping the key. Since the behaviour I just described does not apply to form's, the INS key is always trapped.

So, the question is: Why do you want to trap the INS key? What goal are you trying to achieve?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Well, ALT always is a bad idea for hotkeys.

It's reserved for
1. activating the system menu
2. access keys (if you use \< in a label caption, for example)

I think we already had several threads here about keypress, especially with ALT key. Maybe take a look at what Tamar posted in thread184-1783930

Bye, Olaf.

 

[Dan Freeman]

INS isn't a particularly good keypress to be trapping in any case. It's still used in the old IBM/CUA shortcut keys:

CTRL-INS is Copy
SHIFT-INS is Paste

I'm told these are so deep in Windows' innards that applications that don't natively support them inherit the support.

(And, of course, as Mike says INS alone has its own purpose which is pretty much universal.)

 

[Eugen Fintina]

Actually I don't have any enabled textbox on my form.
My client want to use Ins key as a shortcut for a button that open a form for inserting a new record. Like a replacement to the classic "ALT + KEY". That means that it is not a "must have", but I am confused about this strange behavior. May be it's not so strange, but I am not able to understand it.
Anyway, I want to thank you very much for your answers!

All the best,
Eugen

 

[Olaf Doschke]

Dan is perhaps having the best explanation, besides INS already has the very specific functionality of switching between the insert and the overwrite mode, for example in the VFP IDE. And such keys, also NUM and SHIFTLOCK/CAPS are no good candidates for hotkeys anyway. If customers ask for such hotkeys they typically have a low understanding of windows basics. You can't override and turn off the default behavior of such system keys and even in case it worked you'd always have a double effect not intended.

You should offer him to label a button for starting a new record form with the caption \<New, which causes the look New with underlined N and lets ALT+N click it. Users get used to this hinting on ALT+underlined letter causing the click of that button. When you set a label to such a caption ALT+letter will focus the control with next tabindex, so Labels also can be used for enabling focusing the control they label, without being part of the control itself as on the button and checkbox and options.

That's the intended access key mechanism and it's mainly based on letters for that reason, not any special keys.

Bye, Olaf.