[VB6] Is this a VB6 bug? Why does Toolbar fire Validate event of a TextBox?

[jalexm]

Hello.
I have some TextBoxes and a Toolbar in a Form.
When I click on any Toolbar button or even on the empty part of the Toolbar, the Validate event of the TextBox is fired. Very weird!
Is this a bug? Or am I doing something wrong?

[Spoo]

JA

Could you possibly attach a partial screen-shot
of your form

Spoo

[jalexm]

JA
Could you possibly attach a partial screen-shot
of your form
Spoo

In fact, it's not a problem with my form or my code.
You can run a test easily:
- Put a TextBox and a Toolbar in a form.
- Insert some buttons in Toolbar.
- Write a very simple Validate event for TextBox:

Private Sub Text1_Validate(Cancel As Boolean)
   If Text1.Text = Empty Then
      MsgBox "This field can not be empty."
      Cancel = True
   End If
End Sub

- Run this test.
- Click on some Toolbar button or on the empty part of Toolbar.
- Validate event of Text1 fires. This is not correct.

[Spoo]

JA

OK, you got me on that one.
Sorry, I don't have an answer.

Spoo

[techgnome]

you added the text box to the form first didn't you? The Textbox has focus... when you click the toolbar, it loses focus... one of the events that fires as part of this process is the Validate event... then the LostFocus .... the Validate event allows you to check the data and if necessary, set the cancel to prevent the focus from going somewhere else... can't do that in the LostFocus because by then it's too late, focus is gone.

-tg

[jalexm]

you added the text box to the form first didn't you?

Maybe. I can't remember. Is there any difference adding one or another control first? Please, explain it.

The Textbox has focus... when you click the toolbar, it loses focus... one of the events that fires as part of this process is the Validate event... then the LostFocus .... the Validate event allows you to check the data and if necessary, set the cancel to prevent the focus from going somewhere else... can't do that in the LostFocus because by then it's too late, focus is gone.

I'm not sure if TextBox loses its focus when you click on Toolbar because Toolbar should not get focus anyway. Also, if Validate event is removed and you write a LostFocus event to TextBox, this event is not fired when you click on Toolbar.

Well, any solution or is this a VB6 bug?

[Spoo]

JA

Had a thought ...

I haven't worked with a Toolbar control, but it
probably has a CausesValidation Property. If so,
it would be set to True by default.

Solution: In your form load sub, set it to False.

Spoo

[gibra]

I'm not sure if TextBox loses its focus when you click on Toolbar because Toolbar should not get focus anyway. Also, if Validate event is removed and you write a LostFocus event to TextBox, this event is not fired when you click on Toolbar.

Well, any solution or is this a VB6 bug?

Isn't a bug.
It's correct.


Validate event ISN'T similar to LostFocus event.

[jalexm]

JA

Had a thought ...

I haven't worked with a Toolbar control, but it
probably has a CausesValidation Property. If so,
it would be set to True by default.

Solution: In your form load sub, set it to False.

Spoo

Toolbar hasn't a CausesValidation property because it's designed to not receive focus and not fire Validate event in others controls.
Thanks for your help anyway.

[jalexm]

Isn't a bug.
It's correct.
Validate event ISN'T similar to LostFocus event.

Sorry, I think you didn't read the entire post.
We are not worried about LostFocus or Validate. We know how they work.
The problem is Toolbar firing a Validation event of TextBox (or any other control). It should not do this since it's designed to not receive focus. That's the real problem.
But thanks for your help anyway.

[Spoo]

JA

I've got Microsoft Windows Common Controls 6.0 checked
on my Components list, but no Toolbar control on my Toolkit.

Where is it located?

Spoo

[jalexm]

JA

I've got Microsoft Windows Common Controls 6.0 checked
on my Components list, but no Toolbar control on my Toolkit.

Where is it located?

Spoo

I can't remember exactly 'cause I don't have VB6 installed here at this moment (I'm at home now). I think it's MSCOMCTL.OCX, but I'm not sure.

[Spoo]

JA

Your memory is pretty damn good .. turns out MSCOMCTL.OCX
is precisely Microsoft Windows Common Controls 6.0, and the
Toolbar control was there all along ..

And, as you stated, there is no CausesValidation Property.

Obviously I'm not a power-user either of this control or of
the Validate event for the Textbox, so I'm not one to address
the "is this a VB6 bug" issue.

A thought regarding a work-around ..

Could you perhaps declare a Public var that is updated on
a Toolbar ButtonClick event, and then somehow utilize this
var's setting in the TextBox Validate event to induce an
"ignore" of the need to validate?

Spoo

[jpbro]

I don't use the Toolbar control myself, so this is purely speculation but:

I can imagine that clicking the toolbar has been designed to raise Validate events because in many ways toolbars can act like buttons. For example, let's say you have a Save button on your toolbar - you'd likely want validate events to fire before you performed your save operation.

How about this test: if you set Cancel = True in the TextBox validate event, does the Toolbar button clicked event still fire?

[jcis]

I'm agree 100% with jpbro here, and the answer for his question is no, the toolbar button click event won't fire when Cancel = True in Text1_Validate event.

I will end saying the same that jpbro already said here, but just as a second explanation:

All this is not related to focus or not focus, in fact the toolbar can't get focus (as jalex already said), that's true, and the textbox won't loose focus when cancel = true, so the reason Validate event is fired is: You can't execute any event from VB until you enter valid data into the Textbox, any action that would lead to an event to fire won't be allowed by VB until the Textbox has valid input. As jpbro stated a toolbar button click event or even a toolbar_click event could fire a process that uses the data in Text1, VB won't let this happen until Text1 content is valid.

No one would want any process to start running when the input is not correct. So in short: Validate event will always fire, but it wil only let other events occur when Calcel = False. If Cancel = True (validation not ok) then the rest of the application won't be accessible to the user until he enters valid data in that control.

[jalexm]

Could you perhaps declare a Public var that is updated on a Toolbar ButtonClick event

In this case, Toolbar_ButtonClick event is NOT fired and Text1_Validate is fired when you click on a Toolbar button or on empty part of Toolbar.

For example, let's say you have a Save button on your toolbar - you'd likely want validate events to fire before you performed your save operation.

OK, but if you have a Clear button so that the user can clear all the form, this will not work.

How about this test: if you set Cancel = True in the TextBox validate event, does the Toolbar button clicked event still fire?

Validate event is always fired, no matter the value of Cancel.

So in short: Validate event will always fire, but it wil only let other events occur when Calcel = False. If Cancel = True (validation not ok) then the rest of the application won't be accessible to the user until he enters valid data in that control.

What about a Clear button as I said before? I think Text1_Validate firing is not a real problem, but Toolbar never can have buttons like Clear, Exit Without Saving, or things like that.

Maybe a solution to this problem is to set PlaceHolder style to a button in Toolbar and insert a normal button on that when we need a Clear button. I have not tested this yet.

All this problem would be solved if buttons on Toolbar had a CausesValidation property.

[techgnome]

"Text1_Validate firing is not a real problem" -- so WHAT is the problem? If you don't care that the validate is event is firing or not then what the heck are we doing in this thread?

Of COURSE the toolbar is going to get focus... you can't click a control w/o it getting focus (few exceptions to that... but generally speaking anything that is used for user input is going to get focus when clicked.)

-tg

[jpbro]

It is a problem for your use case jalexm - some Google searching turned up other people with the same issue, but unfortunately no solutions.

I think you are stuck with some really ugly hack to determine the mouse position (is it over a toolbar button with the mouse down when the Validate event is called), or switch to a different toolbar control that has a CausesValidation property for its buttons.

[jalexm]

"Text1_Validate firing is not a real problem" -- so WHAT is the problem? If you don't care that the validate event is firing or not then what the heck are we doing in this thread?

I meant Toolbar should not fire Validate, but since it does we could use it as said before (Save button, for example). We can´t avoid Toolbar firing Text1_Validate since there´s no CausesValidation property to set. So it´s impossible to use a Clear button. So it´s an "incomplete" control and it´s almost useless, in my opinion.

Also, I tested PlaceHolder style and did not like it. It´s easier to add buttons to the Form than to the Toolbar, but it´s only my opinion.

Of COURSE the toolbar is going to get focus... you can't click a control w/o it getting focus

Well, since there´s no GotFocus/LostFocus event available to Toolbar, maybe we could think of it as without it getting focus.