[AccessD] OK versus Cancel

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