Re: onKeyPress[Screen]
----- 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.
|
Not Categorized, Please Help
|
|
