Re: onKeyPress[Screen]
- Posted by George Walters <gwalters at sc.rr.com> Aug 02, 2001
- 435 views
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. > > > > >