McGillivray, Don [IT]
Donald.A.McGillivray at sprint.com
Mon Feb 23 11:38:42 CST 2009
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.
More information about the AccessD mailing list