Validating control and preventing loss of focus... 
Author Message
 Validating control and preventing loss of focus...

This is an issue that I've toyed with on and off for a couple years now.

Does anybody have a way, using sub-classing controls or APIs to validate
the contents of a control before it loses the input focus (just like the
Access combo box does with the NotInList event)?  In other words, I don't
want any events to fire in other controls before the control that
currently has the focus has been validated.  That means no GotFocus
events, button Click events (try preventing these if the button has an
access key defined - the Click event actually runs before the GotFocus!),
etc.

I've tried several different approaches to this problem and have yet to
come up with a viable solution...

Anybody?

Geoff

-----------------------
"I brake for MCSD's..."
-----------------------



Mon, 26 Oct 1998 03:00:00 GMT  
 Validating control and preventing loss of focus...

Have you tried the 'change event'?



Wed, 28 Oct 1998 03:00:00 GMT  
 Validating control and preventing loss of focus...

Philip
        The change event isn't sufficient if you want to check the validation
in some sort of context. It's OK if all you want to check is whether the users
entered characters they shouldn't, but if you want to check if they've entered
a word or number they shouldn't you can't really check until they've left the
control - ie finished stuffing about with backspace,del etc.
        This means playing with the GotFocus, Lost Focus Events, and using the
SetFocus method.
Phil


Quote:

>Have you tried the 'change event'?



Thu, 29 Oct 1998 03:00:00 GMT  
 Validating control and preventing loss of focus...

Geoff,
        This is a real problem with VB and has been for ages.We've had the
same problem. We've tried all sorts of schemes, state flags etc but nothing
really worked.
        The basic problem is that the GotFocus and LostFocus events are
triggered simultaneously, rather than sequentially when someone clicks or tabs
about a form. This means that it is impossible to predict whats happening,
thus impossible to control focus upon a validation error.
        Vantage Point software have a control called VFocus which serialises
the events, letting you force focus back to an erroneous control. Their web
site is www.vpsoft.com and they have a very good dicsussion in a white paper
(called "Hocus Pocus, who's got Focus") on the focus problem, basically saying
that it is impossible to solve , microsoft says its too hard to solve you
should use form level validation anyway, and that Vantage Points control will
solve everything.
        We've actually put money down for the OCX version of this software
because we need it urgently (not too expensive), but they havn't delivered
yet.The OCX is still in beta.  I'll email you with the results if you like.
        In the meantime for our first release we've implemented form level
validation, changing colours of bad text boxes similiar to the way Word 6
underlines misspelt words. Looks OK, but we'd rather not let any bad data get
into the text boxes at all.
Phil


Quote:

>This is an issue that I've toyed with on and off for a couple years now.

>Does anybody have a way, using sub-classing controls or APIs to validate
>the contents of a control before it loses the input focus (just like the
>Access combo box does with the NotInList event)?  In other words, I don't
>want any events to fire in other controls before the control that
>currently has the focus has been validated.  That means no GotFocus
>events, button Click events (try preventing these if the button has an
>access key defined - the Click event actually runs before the GotFocus!),
>etc.

>I've tried several different approaches to this problem and have yet to
>come up with a viable solution...

>Anybody?

>Geoff

>-----------------------
>"I brake for MCSD's..."
>-----------------------



Thu, 29 Oct 1998 03:00:00 GMT  
 Validating control and preventing loss of focus...

Quote:

> Geoff,
>         This is a real problem with VB and has been for ages.We've had the
> same problem. We've tried all sorts of schemes, state flags etc but nothing
> really worked.
>         The basic problem is that the GotFocus and LostFocus events are
> triggered simultaneously, rather than sequentially when someone clicks or tabs
> about a form. This means that it is impossible to predict whats happening,
> thus impossible to control focus upon a validation error.
> ...
> ...
> Phil
> On Friday, I was working with a subclassing control and using the SetCapture

API to prevent the user from clicking anywhere else on the form (including
command buttons).  Then to prevent the user from tabbing, I wrote a routine
that goes through the form and saves all the controls' TabStop property before
setting them to false to prevent the user from tabbing out of the control (I
didn't check to see if the access key problem still exists - though it
probably does).

The problem I was having was that the SetCapture seemed to be getting released
when I clicked or (especially) double-clicked and so I had to keep
"recapturing" it in the MouseUp event to prevent that.  Another problem was
that when I clicked to a different application (under Win95), when I came back
the capture was gone, so I tried unsuccessfully (thus far) to trap the
WM_ACTIVATEAPP message on my form (which is not an MDI child or parent).  I am
just going to have to keep tinkering with it as I have time, and I am confident
that I will be able to wrap this functionality up into a class which will make
it fairly easy to use.  However, I still don't like how unreliable the mouse
capture is.

My response to Microsoft's statement that we should use form validation is that
it seems somewhat contradictory.  Saying that we should not try to use control
validation in VB seems like a cover for their inability to present a solution
They have provided this ability in Access, and although they are not true
windows controls, doesn't that seem just a little contradictory?

Geoff

Quote:


> >This is an issue that I've toyed with on and off for a couple years now.

> >Does anybody have a way, using sub-classing controls or APIs to validate
> >the contents of a control before it loses the input focus (just like the
> >Access combo box does with the NotInList event)?  In other words, I don't
> >want any events to fire in other controls before the control that
> >currently has the focus has been validated.  That means no GotFocus
> >events, button Click events (try preventing these if the button has an
> >access key defined - the Click event actually runs before the GotFocus!),
> >etc.

> >I've tried several different approaches to this problem and have yet to
> >come up with a viable solution...

> >Anybody?

> >Geoff

> >-----------------------
> >"I brake for MCSD's..."
> >-----------------------



Fri, 30 Oct 1998 03:00:00 GMT  
 Validating control and preventing loss of focus...

Philip et al,

I wrote an OCX named Validate for Mabry Software to address this
problem.  I have had it out for some testing and while it works very
well for text boxes and other controls there are still problems
associated with command buttons.  For instance, the escape key will
cause a call into the Click event of a command button having the
Cancel property set to true.  I have not been able to thwart that
particular VB behavior and so have been hesitant to push sales of the
control.

Does it seem reasonable to you to have to deal with some special cases
such as that?  I'd like to have a few more testers and will send a
beta copy to the first 3 people who send me e-mail.




Sat, 31 Oct 1998 03:00:00 GMT  
 Validating control and preventing loss of focus...

Quote:

>This is an issue that I've toyed with on and off for a couple years now.
>Does anybody have a way, using sub-classing controls or APIs to validate
>the contents of a control before it loses the input focus (just like the
>Access combo box does with the NotInList event)?  In other words, I don't
>want any events to fire in other controls before the control that
>currently has the focus has been validated.  That means no GotFocus
>events, button Click events (try preventing these if the button has an
>access key defined - the Click event actually runs before the GotFocus!),
>etc.
>I've tried several different approaches to this problem and have yet to
>come up with a viable solution...
>Anybody?
>Geoff

Hello Geoff,

I've been toying with the same problem for at least as long
as you.

I haven't checked vb4 but believe that with vb3 that there
is no general simple way of solving this problem. We should
look to Microsoft to include a function which allows us to
validate an input control just after it has been entered, if VB4
does not already allow this. Other languages allow this to be
simply done, eg. the canDepart method in Paradox.

How to get Microsoft to listen is the problem!

I believe that I have solved the problem where only text controls
are involved and am emailing a sample form to you. The method
used involves validating each field in the LostFocus event process
and forcing the focus back to the invalid control if it is deemed
to be in error. This sounds simple but has its ins and outs!

Could it be that what we are trying to do is not worth the effort
and that we should be satisfied with the validation of all entered
controls after the user has finished his input operations, ie on a
whole Form basis??

Eric



Sat, 31 Oct 1998 03:00:00 GMT  
 Validating control and preventing loss of focus...

Quote:

>I haven't checked vb4 but believe that with vb3 that there
>is no general simple way of solving this problem. We should
>look to Microsoft to include a function which allows us to
>validate an input control just after it has been entered, if VB4
>does not already allow this. Other languages allow this to be
>simply done, eg. the canDepart method in Paradox.

Certainly this can be done. MS Access includes BeforeUpdate and
AfterUpdate events for controls and forms. Now we just need to
have MS add this to VB.


Cheers,

Joe

Never underestimate the power of a WAG.



Sat, 31 Oct 1998 03:00:00 GMT  
 Validating control and preventing loss of focus...

Quote:

>I believe that I have solved the problem where only text controls
>are involved and am emailing a sample form to you. The method
>used involves validating each field in the LostFocus event process
>and forcing the focus back to the invalid control if it is deemed
>to be in error. This sounds simple but has its ins and outs!
>Could it be that what we are trying to do is not worth the effort
>and that we should be satisfied with the validation of all entered
>controls after the user has finished his input operations, ie on a
>whole Form basis??
>Eric

To address your last question...

I vote for not worth the effort. I have deadlines to meet and
app-level problems to think about...

Given the constraints we've got, and my keep-it-simple-stupid (KISS)
philosophy, I've settled on background color warnings on lost-focus
events (with a status line description if necessary), and form-level
thorough validation at "Ok" button time. Users get to liking this
approach because (especially the old hands) don't have to look at the
window when they hit the tab key to figure out which field they're in.
When they hit the tab key they KNOW they are in the next field. If
they want to see if they've made a mistake they can look for the
"warning yellow" background. And at the OK/Save button, they can rest
assured that I'm going to tell them exactly what they did wrong (and
should do right) anyway.

I'm currently working on some windows I inherited that fumble all over
themselves dealing with the focus problem. I've ripped all that code
out and made them smaller, easier to maintain, and more conistent and
predictable for the users. These windows are now about HALF their
former weight in code. Win/win...

Sometimes we try way too hard to force the user down a path that is
unnecessarily restricted. Relax! For example, I never use masked edit
controls anymore (well, maybe on special occassions). They only serve
to make it harder on the user and easier on me. I let the user put any
format for a date they want and *I* figure out if it's a date and
format it for internal use. You can reformat it in the lost focus
event and slap it right back into the control if you want, but don't
hold them hostage making them enter it in a specific format before
moving on. That is not in the spirit of Windows/friendly GUI.

<soapbox withdrawn>

---
Wes Williamson
Sabre Decision Technologies



Sat, 31 Oct 1998 03:00:00 GMT  
 Validating control and preventing loss of focus...

Quote:


> ...
> ...
> ...
>...event and slap it right back into the control if you want, but don't
>hold them hostage making them enter it in a specific format before
>moving on. That is not in the spirit of Windows/friendly GUI.

><soapbox withdrawn>

When you want to perform action similar to the Access combo's NotInList
event, however, this is important.  If the user types something in a combo
box, I think they should be prompted right then and there whether or not
they want to add the item to the list (not 15 minutes later after they
return from the bathroom).

I know that it is not this simple for Microsoft to implement, but wouldn't
it be awesome if you could do the following?

Private Sub Combo1_LostFocus(Cancel As Integer)
   If Combo1.Text = "Wrong Answer" Then _
      Cancel = True
End Sub

Dream on...

Geoff
-----------------------
"I brake for MCSD's..."
-----------------------



Sun, 01 Nov 1998 03:00:00 GMT  
 Validating control and preventing loss of focus...

Quote:



>> ...
>> ...
>> ...
>>...event and slap it right back into the control if you want, but don't
>>hold them hostage making them enter it in a specific format before
>>moving on. That is not in the spirit of Windows/friendly GUI.

>><soapbox withdrawn>
>When you want to perform action similar to the Access combo's NotInList
>event, however, this is important.  If the user types something in a combo
>box, I think they should be prompted right then and there whether or not
>they want to add the item to the list (not 15 minutes later after they
>return from the bathroom).

I don't entirely agree. The user is interested in (for example) adding
the customer, not administering their database of possibilities for
future entries. IMHO, it's a little rude to ask the user to consider
the current entry and think about future entries and make a decision
about whether he might want that choice to be there in the future
before he can get to the Phone Number field. It has ABSOLUTELY NOTHING
to do with the current task.

Do you ask the user if he wants to delete ones that haven't been used
in ages? If not, this is a one-way list that grows and grows.

Unfortunately, there's no perfect answer here. Personally, if it was
absolutely necessary to build a database of combo box entries, I think
I'd make the list an intelligent application of most-recently and/or
most-often used values. That way over time the list doesn't become
full of misspellings, variations, and/or obsolete values, and noone
has to administer it. OR if they can't find the entry in the dropdown
list, they could choose a special entry that says "** Add New Blivet
**" at which time you present them with the Blivet administration
window. That sucks too, but they only get interrupted if they NEED a
new one.

There has just got to be a GUI solution that better addresses this
particular problem. When my brow wrinkles and I begin losing hair over
a problem, a little alarm goes off telling me it's time to start
thinking from outside the problem rather than from within.

Quote:
>Dream on...

I am.. I am...

---
Wes Williamson
Sabre Decision Technologies



Mon, 02 Nov 1998 03:00:00 GMT  
 Validating control and preventing loss of focus...

Quote:




>>> ...
>>> ...
>>> ...
>>>...event and slap it right back into the control if you want, but don't
>>>hold them hostage making them enter it in a specific format before
>>>moving on. That is not in the spirit of Windows/friendly GUI.

>>><soapbox withdrawn>

>>When you want to perform action similar to the Access combo's NotInList
>>event, however, this is important.  If the user types something in a combo
>>box, I think they should be prompted right then and there whether or not
>>they want to add the item to the list (not 15 minutes later after they
>>return from the bathroom).

>I don't entirely agree. The user is interested in (for example) adding
>the customer, not administering their database of possibilities for
>future entries. IMHO, it's a little rude to ask the user to consider
>the current entry and think about future entries and make a decision
>about whether he might want that choice to be there in the future
>before he can get to the Phone Number field. It has ABSOLUTELY NOTHING
>to do with the current task.

Ahh... but you are assuming that the user is adding a customer.  What if
the "user" is adding a bug report to a log and they want to add it to a
Category that doesn't exist?  Shouldn't they be able to type a category
name in that combo box that doesn't exist, and then be prompted (right
then - not during form validation) if they want to create that category,
rather than have to load up some other maintenance form to make a single
entry and then return to the bug report?  I say, without hesitation, a
resounding YES!  If you say no, then it's your perogative as an individual
not to use the wonderful NotInList event (or the LimitToList property) in
your Access development...

However, if your users are doing nothing but doing heads-down data entry
of customers, whose information should fit into fairly static domain,
and speed is a concern, then I completely agree.  I just think that there
are some places where this kind of flexibility is sorely missed in
non-Access applications...

Quote:

>>Dream on...

>I am.. I am...

>---
>Wes Williamson
>Sabre Decision Technologies


Geoff
-----------------------
"I brake for MCSD's..."
-----------------------


Mon, 02 Nov 1998 03:00:00 GMT  
 Validating control and preventing loss of focus...

Quote:



>>> ...
>>> ...
>>> ...
>>>...event and slap it right back into the control if you want, but don't
>>>hold them hostage making them enter it in a specific format before
>>>moving on. That is not in the spirit of Windows/friendly GUI.

>>><soapbox withdrawn>

>>When you want to perform action similar to the Access combo's NotInList
>>event, however, this is important.  If the user types something in a combo
>>box, I think they should be prompted right then and there whether or not
>>they want to add the item to the list (not 15 minutes later after they
>>return from the bathroom).

>I don't entirely agree. The user is interested in (for example) adding
>the customer, not administering their database of possibilities for
>future entries. IMHO, it's a little rude to ask the user to consider
>the current entry and think about future entries and make a decision
>about whether he might want that choice to be there in the future
>before he can get to the Phone Number field. It has ABSOLUTELY NOTHING
>to do with the current task.

.. but you are assuming that the user is adding a customer.  What if
the "user" is adding a bug report to a log and they want to add it to a
Category that doesn't exist?  Shouldn't they be able to type a category
name in that combo box that doesn't exist, and then be prompted (right
then - not during form validation) if they want to create that category,
rather than have to load up some other maintenance form to make a single
entry and then return to the bug report?  I say, without hesitation, a
resounding YES!  If you say no, then it's your perogative as an individual
not to use the wonderful NotInList event (or the LimitToList property) in
your Access development...

However, if your users are doing nothing but doing heads-down data entry
of customers, whose information should fit into fairly static domain,
and speed is a concern, then I completely agree.  I just think that there
are some places where this kind of flexibility is sorely missed in
non-Access applications...

Quote:

>>Dream on...

>I am.. I am...

>---
>Wes Williamson
>Sabre Decision Technologies


Geoff
-----------------------
"I brake for MCSD's..."
-----------------------


Mon, 02 Nov 1998 03:00:00 GMT  
 Validating control and preventing loss of focus...

Quote:





>>>>...event and slap it right back into the control if you want, but don't
>>>>hold them hostage making them enter it in a specific format before
>>>>moving on. That is not in the spirit of Windows/friendly GUI.

>>>When you want to perform action similar to the Access combo's NotInList
>>>event, however, this is important.
>>I don't entirely agree. The user is interested in (for example) adding
>>the customer, not administering their database of possibilities for
>>future entries.
>...Shouldn't they be able to type a category
>name in that combo box that doesn't exist, and then be prompted (right
>then - not during form validation) if they want to create that category,
>rather than have to load up some other maintenance form to make a single
>entry and then return to the bug report?
>I just think that there are some places where this kind of flexibility
>is sorely missed in non-Access applications...

You are right. Maybe I'm a little off track. True, it would be nice to
have the NotInList event. It would save me having to write the code
that searches through the combo list. But does this have anything to
do with preventing focus loss? You can still prompt the user, but
having done so, allow the focus to move on to the next control. Hmmmm.
It's been a few days (I've slept a few times since this discussion
started :) ), and perhaps I've lost focus on the problem we're trying
to solve (pun intended).

I'm the last person to argue for argument's sake. I'm sure there are
many situations where what you want is exactly what you need. I guess
my point is that we've got what we've got and it ain't all that bad,
and there is probably a good solution currently available. However it
does take folks like you to be proactive and lobby for the features in
5.0 so that lazy guys like me can take advantage of those features
later. So go get 'em! :)

---
Wes Williamson
Sabre Decision Technologies



Tue, 03 Nov 1998 03:00:00 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. WebBrowser Control losses focus when minimized

2. Label on MS Tabbed Dialog control prevents validate event firing when changing tabs

3. Setting focus to a control in a validating sub

4. textbox validate event not being fired when sstab controls gets focus

5. PRB: Preventing a scrollbar control from receiving focus.

6. PRB: Preventing a scrollbar control from receiving focus.

7. PRB: Preventing a scrollbar control from receiving focus.

8. Loss of Focus on a VB Form when calling ViewReport using the CRViewer

9. Validate form and prevent it from closing

10. Any ways to make focus on Label control like focus in button control

11. Moving focus without triggering validate

12. textbox focus from within validate event

 

 
Powered by phpBB® Forum Software