Globally Trap Escape Key
in [Visual Basic]
|
From: Daryl Muellenberg on 31 Mar 2010 13:27 "Jeff Johnson" <i.get(a)enough.spam> wrote in message news:%23UiJT4D0KHA.6124(a)TK2MSFTNGP02.phx.gbl... > "Daryl Muellenberg" <dmuellenberg(a)comcast.net> wrote in message > news:33FB3D6D-9976-4EA8-9295-D0B942EFBD66(a)microsoft.com... > >> This is not a good idea if your app is designed for general (not >> personal) use. The Cancel button is standard and the user knows the >> purpose of the button. Without the button on the screen, how does the >> user know that the Esc key cancels his/her changes? > > There are lots of applications where Esc is used in this way. Off the top > of my head: Access. > I'm not saying that you shouldn't use the Esc key to cancel changes, just that there should be some other visual graphic to perform the cancel operation. I don't have Access installed so I can't verify right now, but I do have Excel and Esc will also cancel changes in Excel but there is also an 'X' button on the toolbar that the user can press to perform the cancel, so I assume that Access does the same thing.
From: Jeff Johnson on 31 Mar 2010 14:09 "Daryl Muellenberg" <dmuellenberg(a)comcast.net> wrote in message news:45D53973-4270-48F4-A29E-0C453961A6A4(a)microsoft.com... >>> This is not a good idea if your app is designed for general (not >>> personal) use. The Cancel button is standard and the user knows the >>> purpose of the button. Without the button on the screen, how does the >>> user know that the Esc key cancels his/her changes? >> >> There are lots of applications where Esc is used in this way. Off the top >> of my head: Access. >> > I'm not saying that you shouldn't use the Esc key to cancel changes, just > that there should be some other visual graphic to perform the cancel > operation. I don't have Access installed so I can't verify right now, but > I do have Excel and Esc will also cancel changes in Excel but there is > also an 'X' button on the toolbar that the user can press to perform the > cancel, so I assume that Access does the same thing. No, it doesn't. There is no visual indicator in Access (at least up to 2003) for "cancel changes to field/record."
From: Karl E. Peterson on 31 Mar 2010 14:22 Jeff Johnson wrote: > "MikeD" <nobody(a)nowhere.edu> wrote in message > news:%23dS6$cF0KHA.1796(a)TK2MSFTNGP02.phx.gbl... > >>> I personally feel that the hidden button with Cancel = True is cheesy, >>> cheesy, cheesy. Use KeyPreview, plain and simple. >> >> Why?!? > > Mind you I'm talking about the "hidden" cancel button scenario, where you put > a button on the form but make it permanently invisible by making its > coordinates -1000, -1000 or something like that and its only purpose for > existing to to trap the Esc key. If the app was going to have a Cancel > Changes button in plain view of the users then setting Cancel = True on that > button makes perfect sense. I think that's the gut-check issue, on the "hidden" button, here. Creating a window for something another already existing window can already do quite easily with just a little bit of code. Just isn't right. -- ..NET: It's About Trust! http://vfred.mvps.org
From: MikeD on 31 Mar 2010 18:18 "Karl E. Peterson" <karl(a)exmvps.org> wrote in message news:u3SMp8P0KHA.3676(a)TK2MSFTNGP05.phx.gbl... > Jeff Johnson wrote: >> "MikeD" <nobody(a)nowhere.edu> wrote in message >> news:%23dS6$cF0KHA.1796(a)TK2MSFTNGP02.phx.gbl... >> >>>> I personally feel that the hidden button with Cancel = True is cheesy, >>>> cheesy, cheesy. Use KeyPreview, plain and simple. >>> >>> Why?!? >> >> Mind you I'm talking about the "hidden" cancel button scenario, where you >> put a button on the form but make it permanently invisible by making its >> coordinates -1000, -1000 or something like that and its only purpose for >> existing to to trap the Esc key. If the app was going to have a Cancel >> Changes button in plain view of the users then setting Cancel = True on >> that button makes perfect sense. > > I think that's the gut-check issue, on the "hidden" button, here. > Creating a window for something another already existing window can > already do quite easily with just a little bit of code. Just isn't right. > Perhaps I'm looking at it a different way than you 2 are. Now, I think you're both saying to use the form's KeyPreview and write code to handle the Esc key in that. That's fine and dandy. BUT...the code in the form's KeyPress event is going to fire an awful lot (with every keypress the user makes while the form is active). Using a command button which is way off of the form eliminates the needless execution of that code over and over. I see nothing cheesy about it if the purpose is to execute code solely when Esc is pressed regardless of what control has focus. -- Mike
From: Karl E. Peterson on 31 Mar 2010 18:27
MikeD wrote: >>>>> I personally feel that the hidden button with Cancel = True is cheesy, >>>>> cheesy, cheesy. Use KeyPreview, plain and simple. >>>> >>>> Why?!? >>> >>> Mind you I'm talking about the "hidden" cancel button scenario, where you >>> put a button on the form but make it permanently invisible by making its >>> coordinates -1000, -1000 or something like that and its only purpose for >>> existing to to trap the Esc key. If the app was going to have a Cancel >>> Changes button in plain view of the users then setting Cancel = True on >>> that button makes perfect sense. >> >> I think that's the gut-check issue, on the "hidden" button, here. Creating >> a window for something another already existing window can already do quite >> easily with just a little bit of code. Just isn't right. > > Perhaps I'm looking at it a different way than you 2 are. Now, I think you're > both saying to use the form's KeyPreview and write code to handle the Esc key > in that. That's fine and dandy. BUT...the code in the form's KeyPress event > is going to fire an awful lot (with every keypress the user makes while the > form is active). Using a command button which is way off of the form > eliminates the needless execution of that code over and over. I see nothing > cheesy about it if the purpose is to execute code solely when Esc is pressed > regardless of what control has focus. Well, yeah, the event will fire a lot. Maybe. But what's a lot? At most, a few hundred times a minute? If this application has the foreground focus, which it undoubtedly does, that's not going to put any sort of measurable dent on system performance. I guess I'm saying I disagree with the stated goal -- preventing the execution of code -- in this case, because in reality it's just not very much code at all. Afterall, the form's windowproc is already sinking the keypress and so on and so on. The only additional "overhead" is a call to the event code, which can immediately return after testing a value passed on the stack. That all said, I agree that the savings of one less window is also relatively pitiful in this day and age. But I think I still fall that way, with out ever actually mentioning *cheese* myself! <g> -- ..NET: It's About Trust! http://vfred.mvps.org |