Re: onKeyPress[Screen]
Derick and Irv...
Well when this job is done I would hope to move some of my existing
customers over to the window's product...without a great deal of burden..I
agree that I certainly won't violate standard windows UI, but hidden behind
the system it would be nice for current users of my software to have some
familiar controls without losing the windows UI. I may abandon this at some
point if it becomes to troublesome. This is what I have done at present ..
--------------------- key press routines -------------------
procedure keyPressProcess(integer keyCode,integer shift)
if mode = 0 then
keyCode = upper(keyCode)
if keyCode = 'X' then
processExit()
elsif keyCode = 'N' then
processNext()
elsif keyCode = 'P' then
processPrev()
elsif keyCode = 'F' then
processFind()
elsif keyCode = 'A' then
processAdd()
elsif keyCode = 'S' then
processSettab()
elsif keyCode = 'C' then
processChange()
elsif keyCode = 'D' then
processDelete()
elsif keyCode = 'V' then
processSave()
elsif keyCode = 'B' then
processAbort()
end if
end if
end procedure
If 'mode' is zero then no data entry is in progress on the screen and the
button activation by keypress would work. If the user is in add or change
mode on the screen then mode = Add or mode = Change and the buttons would
not work with letters..the only missing item here is the 'esc' key. I
haven't done anything about it. I could place it before the 'if mode = 0' .
...george
----- Original Message -----
From: "Derek Parnell" <ddparnell at bigpond.com>
To: "EUforum" <EUforum at topica.com>
Sent: Thursday, August 02, 2001 5:14 PM
Subject: Re: onKeyPress[Screen]
>
>
> ----- Original Message -----
> From: "Irv Mullins" <irvm at ellijay.com>
> To: "EUforum" <EUforum at topica.com>
> Sent: Friday, August 03, 2001 6:48 AM
> 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
|
|
