"Bob Butler" <butlerbob@[EMAIL PROTECTED]
> wrote in message
news:fa10fb0.0312140710.786efad4@[EMAIL PROTECTED]
> "Randi" <RSaddler@[EMAIL PROTECTED]
> wrote in message
news:<R9TCb.11784$JW3.8837@[EMAIL PROTECTED]
>...
> > Hi All,
> > I have a problem on a username password login form. I use:
> > txtPassword.Text = StrConv(txtPassword.Text, vbProperCase) to
validate the
> > proper case when someone enters their name and password. It work
when you
> > use the button to continue, but if you hit enter on your keyboard
the event
> > apparently doesnt lose focus and it says you entered the wrong
password.
>
> Neither the LostFocus nor Validate events are reliable IMO because
> they do not fire consistently. Clicking toolbar buttons, menu items
> and pressing enter to trigger the default command button are just a
> few cases where they don't happen. You can use them for simple
> validation if you want but never assume that they will run. In this
> case, have the command button code do the StrConv.
I would say the events are reliable, but that controls don't lose focus
in some situations where you might expect them to. I agree that you
should never assume they will be fired, and always put required
processing in a procedure that will definitely run.
LostFocus doesn't fire here because in fact, the textbox never loses
focus. If the default button only popped up a message, focus would
return to the textbox, not the default command button. Similarly,
Validate doesn't fire because it only fires just before a possible loss
of focus.
In many cases, it makes sense that selecting a menu or toolbar button
does not change the focus. If I click the Paste button, for instance, I
appreciate the fact that the focus stays where it is, and the paste
occurs where I intended it.
|
