Option button problem

[CP60]

Anyone knows how to prevent this [bug]?

Option Explicit

Private Sub Form_Load()

    Text1.TabIndex = 0
    Option1.TabIndex = 1
    Option2.TabIndex = 2
    Option3.TabIndex = 3
    
    Option3.Value = True

End Sub

Private Sub Text1_Validate(Cancel As Boolean)

    Option1.Value = True

    'Even though the user didn't click on Option3, and even though in this Validate event the Option1.Value was set to TRUE,
    'after this edit box is validated, the selected option button changes back Option3!
End Sub

 

[strongm]

>the selected option button changes back Option3

I'd suggest that you are only seeing this behaviour when triggering the validate by tabbing out of Text1. And I'd hazard that you'll also notice also that Option3 is highlighted, rather than Option 1 which you might expect given the TabOrder.

This is all down to some low-level handling of windows events and windows focus that VB hides away from us.

The simplest solution would to ensure that that tabbing out of the textbox moved to a different control, but that may not support your form's design.

ANother solution is to use the LostFocus event instead of the Validate event

 

[HughLerwill]

>...use the LostFocus event instead of the Validate event
I favour that because quirkily Validate may be triggered when/ if you happen to Click on a Label.

 

[CP60]

Thanks for the responses.

Yes, when tabbing and the focus is still on Option3.
The business logic calls for these option buttons to come right after the text box.

I figured out that something similar to the follow "works" though:

Private Sub Option1_GotFocus()
    Option2.Enabled = True
    Option3.Enabled = True
End Sub

Private Sub Text1_Validate(Cancel As Boolean)
    
    Option2.Enabled = False
    Option3.Enabled = False
    
    Option1.Value = True
    Option1.SetFocus
  
End Sub

Using a control array makes it even easier to implement.

 

[strongm]

Given that you don't appear to actually be doing any validation, I'd still suggest that you use the LostFocus instead of the Validate event since it needs no such workaround.

 

[CP60]

Given that you don't appear to actually be doing any validation...

The posted code was just for demonstration purposes.

 

[strongm]

So your actual code does do validation?

Frankly, I'd still argue, given that you are trying to muck about with focus in an event that actively prevents focus being mucked about with*, that the LostFocus event is more suitable for your requirements.

(or perhaps set a flag in the Validate event that can subsequently be used in the LostFocus event)



* essentially, what happens when Validate is triggered is that on entry behind the scenes it records where the focus is about to be switched to. On exit either Cancel has been set, in which case focus remains in the triggering control, or it has not - in which case focus is switched to the recorded location (essentially negating any changes in focus you might have made within the validate event). And in the case of an option button, setting the focus to it also causes the value to be set to true ... I hope that this helps explain the behaviour that you are seeing (basically Validate event records that focus is about to be switched to Option3, you change value of Option1 within event, on exit from event focus is switched to remembered control Option3 which has the knock on effect of setting Option3's value to True thus undoing the change you made within the event)

 

[CP60]

Yes, the Code does alot of intensive validating which depends on what the user enters.

Actually, in this mdi application when other mdi child forms can be opened and switched to, or when a modal form is opened by a mdi child, it is usuallay not desired to cause validation when focus is changed to a different mdi child form or a modal form, and that is one of the purposes of using the Validate event here - which I took advantage of after introduced back in the mid-late 90's - to be able to validate the control (and cancel) only when changing focus to a control on the same form, because otherwise, the LostFocus would always fire when focus changeing focus to a different form.

Here with the current situation (never had this exact situation before), the user enters a contractor's ID into the edit box (a required field prior to moving to a different control), or after pressing a function key or clicking a search button next to the edit box, selecting a value from a list shown on a modal form - in which case, no validation should occur at that time!!
Validation should also not occur when changing to a different mdi child form.

After selecting/entering and tabbing/clicking to the next control, an option button's value is set based on a preferred default setting for that selected customer. The user can select a different one then.
In the Option button's click event, is also addition validating code for that control.

I understand that an option button's TabStop is only set to TRUE for the option button which has it's Value property also set to TRUE, and all other option buttons TabStop properties are then set to FALSE.
Therefore, it is then this option button - in the above case Option3 - which causes validation of Text1, and needs to be completed by Option3 unless Cancel is set to TRUE.

You are probably right with the SetFocus. This could also be one of those situations which cause problems if a DoEvents in some proceedure is called when this validate event is executing.

So, I guess I will have to come up with a fix, or have the business rules changed as to which control comes next.

 

[strongm]

>I understand that an option button's TabStop is only set to TRUE for the option button which has it's Value property also set to TRUE, and all other option buttons TabStop properties are then set to FALSE.
Therefore, it is then this option button - in the above case Option3 - which causes validation of Text1, and needs to be completed by Option3 unless Cancel is set to TRUE.

Afraid I disagree

>a fix

Personally I think the flag idea previously mentioned would address this with a minimal amount of recoding and without having to change any business rules