A key difference between VB6 and VB.NET controls is in the order in which they fire the LostFocus and Validate events. VB6 controls fire the Validate event first and then the LostFocus event; if the Validate sets Cancel=True, then the LostFocus event is never fired. The sequence is the same regardless of how the end user moves the input focus away from the control.
Conversely, standard .NET controls fire these events in the same sequence only if end users move the input focus by means of the keyword; if they use the mouse, the control fires a LostFocus event, then the Validating event, and – if the validation fails – another GotFocus event to let the application know that the focus is again on the control.
By default, VB.NET programs created by VB Migration Partner follow the .NET behavior. In most cases, the fact that the LostFocus event fires before the Validate event doesn’t affect the application negatively. For example, consider the following VB6 code:
Private Sub Text1_GotFocus()
Text1.BackColor = vbYellow
Private Sub Text1_LostFocus()
Text1.BackColor = vbWhite
Private Sub Text1_Validate(Cancel as Boolean)
Cancel = (Text1.Text = "")
Now consider the corresponding VB.NET code, as converted by VB Migration Partner. If the end user clicks on a different control and Text1 contains an empty string, the LostFocus event resets the background color to white, then the Validate event cancels the focus shift, and finally the GotFocus event changes the background color to yellow again. The bottom line: the converted VB.NET code works exactly like the original VB6 code.
In some applications, however, the code in the Text1_LostFocus method might depend on some variable that has been set in the Validate event. If this is the case, the converted code might fail or behave unexpectedly.
In such cases, you can force the controls in the support library to behave more closely to the original VB6 controls by setting the VB6Config.FocusEventSupport static property to True:
VB6Config.FocusEventSupport = True
When this property is True, the support library ensures that the LostFocus event is always fired after the Validate event. Notice that in the previously described scenario – the end user moves the focus away with the mouse but the control fails to validate – then a pair of LostFocus/GotFocus events is fired anyway (unlike VB6), but this is seldom a problem.
We recommend that you don’t set the FocusEventSupport property to True unless really necessary, because this setting adds overhead to the standard event dispatching process and might cause other minor annoyances.