Rocky Smolin at Beach Access Software
rockysmolin at bchacc.com
Mon Feb 23 12:00:55 CST 2009
Well, you're right Don - I'm looking at that OK button and wondering why we need it at all. But I just talked to the client and he says if the user enters a password they can click the OK button instead of hitting enter to TAB so leave it there. Rocky Smolin Beach Access Software 858-259-4334 www.e-z-mrp.com www.bchacc.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of McGillivray, Don [IT] Sent: Monday, February 23, 2009 9:39 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] OK versus Cancel I don't think I've EVER seen an application interface that behaves the way your client requests that this one should behave. (Which is not to say that past design ideas must be the basis for future ones.) If the choice to proceed or cancel is being given, then the user MUST choose one action or the other - either by clicking the button or by tabbing to it and pressing the carriage return. If the client doesn't wish to have a choice to bail out before logging in (which is essentially what s/he is saying by telling you to assume OK upon entering the PWD), then get rid of BOTH the OK and cancel buttons. Just be sure that it's understood that the point for a change of mind will be shifted from before login to after the app starts. Just my $0.02 . . . -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Monday, February 23, 2009 9:10 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] OK versus Cancel Dear List: I have a client app which opens to a form displaying log in combo, password text box, a command button labeled OK and a command button labeled Cancel. The Cancel issues Application.Quit. The OK checks the password, and lets the user in of correct. After entering the password the focus shifted to the OK button. So far so good. Then the client wanted the user not to have to click OK after they entered the password - just go right to the switchboard if the password was correct. So I simply added Call cmdOK_Click to the After Update event of the password text box and walla! no need to click OK. But now if the user enters a correct password and clicks Cancel, the program still goes to the switchboard because of the After Update event call. I can't see a way in the After Update event to know that the user clicked Cancel. Screen.ActiveControl.Name still shows txtPassword. The After Update event is triggering before the Cancel click event apparently. Is there a way to know the user clicked Cancel? MTIA, Rocky Smolin Beach Access Software 858-259-4334 www.e-z-mrp.com <http://www.e-z-mrp.com/> www.bchacc.com <http://www.bchacc.com/> -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com