[AccessD] OK versus Cancel

I usually set cmdCancel to not be a tabstop. My users know to to
either type in a password and his tab then stop (two extra keystrokes)
or hit enter twice (one to leave the pw field and the other for OK,
since it is the next control with focus).

I also had a similar request for an ADP and what I did there was to
store and encrypted login and pw in a text/ini file. I would check the
fOSuser name at start up and read the ini file.
If the OSuser name and the last login name are the same, I log them in
automatically.
This only works with split databases, obviously.
The only time they ever have to login is when an update is released.

David


On Mon, Feb 23, 2009 at 9:38 AM, McGillivray, Don [IT]
<Donald.A.McGillivray at sprint.com> wrote:
> 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
>