Re: onKeyPress[Screen]
- Posted by Derek Parnell <ddparnell at bigpond.com> Aug 02, 2001
- 444 views
----- Original Message ----- From: "Irv Mullins" <irvm at ellijay.com> To: "EUforum" <EUforum at topica.com> Subject: Re: onKeyPress[Screen] > > On Thursday 02 August 2001 14:13, George Walters wrote: > > > > Erick and Irv, it would seem here, if i understand this correctly, that all > > keypresses will cause windows to xfer control to my routine. This seems > > like it would be awfully ineficient. would it not be better to somehow give > > windows a table of keys i'm interested in as well as a switch to turn this > > off (like filling in a screen while adding a customer, at which point most > > of those buttons should be disabled) and back on as needed. My doc says > > that onKeyPress requires 2 arguments 1) a keycode for the key of interest > > and 2) a shift var.... is this format defunct now? Or do I have an older > > version of the doc (I'm looking on page 87 of 153 pages. It's also > > certainly possible i'm misreading the doc. > > It's not really inefficient (any more so than Windows in general). > All events (keyclicks, mouse moves, etc,) have to go somewhere, by adding > an onClick event to your main window, you're just getting first crack at the > event before it is passed on down the line to the child controls. I agree too. Some part of the program has to handle the user's keyboard actions. > Just be sure to hook the onClick[George'sMainWindow] event, not > the [Screen], because you still want your users to be able to type info in > with hindrance. Irv, if one does this, the keys "x" and "n" will only behave like George wants them to if no other control has keyboard focus, and that won't happen if there is a button or edit field in the window. The "Screen" control has been specifically designed to cater for this situation. I my opinion, George would be unwise to let the normal keys invoke button actions, because this is not standard Windows UI behaviour. If the window did not have ANY edit fields that use normal keys then this might be acceptable (see the Windows Calculator application for an example). > > Do programmers put their buttons in a separate window from the form being > > filled in? Right now all my stuff is in the same window. However even if > > the buttons are in a separate window one might want to enable the 'esc' > > key to exit the form and go back to the button window. > > Don't try that (please!) > Your Tylenol bill will be huge. Strongly agree with this too. George, this would not be a good idea because it makes the user do too much fiddling around with the physical layout of the window rather than concentrating on the job at hand.