As the Enter and Tab keys are not included in the accelerator key list, how can I trap those keys?

Thanks.

John

John,

For which control do you want to trap them? An edit table? All controls?

- Oystein -

Sorry… all controls.

This is sort of a non-standard request - could you explain what you're trying to do?

Thanks

The Sprezzatura Group

World Leaders in all things RevSoft

Sure. We have an application that prompts the user for an answer to a survey question. There are times when the user may wish to change a application option before they answer the question.

We have a lostfocus on the answer field to validate and process their responses. However, going off the change an option, or leaving the field to go to another field first, all produce a lostfocus event on the answer field - validate/process etc. We don't want that to happen if they do not press the ENTER or TAB key. Any other reason for leaving the answer field is a valid exit that should not process the response.

We tried using GET_EVENT in the answer lostfocus to see where the user was headed. That worked until we realized that if the answer field was empty, we didn't know if that was meant to be a valid answer or they were going off to do something else. (I'm afraid this might be confusing).

Simply, we want to trap the ENTER and TAB keys : they would mean that the user has accepted the value in the answer field (empty or not) as their response. Any other response would indicate they have not yet answered the question.

I hope see is clearer than it seems.

Thanks. John.

John,

Perhaps the easier approach would be to get the FOCUS property in your LOSTFOCUS event. If the focus is on the button (or whatever control) that allows the user to change the application then this will be the value of the FOCUS property. You can then make your logical decisions from that point on.

Doing exactly what you want isn't straightforward and might not be possible without trapping Windows messages and/or sub-classing the processes.

[email protected]

SRP Computer Solutions, Inc.

Thank you, Don. Your last sentence is what we didn't want to hear, but it will save us some time by not worrying about it. We will change the validation process a bit.

Thanks again,

John.

John,

I have a crazy idea. I haven't got time to really check if it works.

Let me first see if I got it right. You have a form with some answer fields. There is a tab order through these answer fields. Also on the form is some other stuff to set options (menus, buttons, check boxes, whatever). As long as the user uses the Tab or Enter key she will move through the answer fields in sequence. That is one type of user behaviour. She can also use the mouse or keyboard shortcuts to click directly on any control (answer field or other control) or invoke an option. That is a different kind of behaviour. You want to distinguish between these two behaviours.

If I got this right read on.

Intersperse your answer fields with secret edit lines, so the tab order alternately visits answer fields and secret edit lines. With secret I mean they must be possible to tab to, but not be visible. I think just putting them outside the window frame would do the trick. Equip each secret edit line with a GOTFOCUS handler. Since the user can never click directly into a secret edit line, such a GOTFOCUS handler only runs when an Enter, Tab or Shift+Tab (back tab) occurred in an answer field. The handler must first check if the movement is forward (i.e, Enter or Tab must have been hit) or backward (i.e, Shift+Tab). If the movement is forward the handler must then do the stuff you want done in the Enter/Tab case. Finally the handler must set focus to the next (if forward movement) or previous control (if backward movement) in tab order, i.e, the next or previous answer field.

Said it was crazy.

- Oystein -

Ha ha ha. Yes it is crazy, but I already tried something like that. :)

What I did was add a GET_EVENT into the answer field (there is only one field) to figure out where they are headed next. The click event was great for this as an actual event is generated. That's what we were trying to do by trapping the ENTER and TAB keys. We were hoping an event could be triggered by those specific keys.

We are getting behind on this project now so we have to move on with what works, but I will keep it in the back of my mind for a future "experimenting" session.

Thanks Oystein.

John.

John,

Yes it is crazy, but I already tried something like that.

That's good to hear. I think I might hate it if I wanted to do something really simple and somebody else suggested a convoluted workaround like that.

- Oystein -

View this thread on the forum...