Most VB6 user controls have been created by means of the ActiveX Control Interface Wizard, which generates tons of VB6 code whose only purpose is remedying the lack of inheritance in VB6. For example, assume that you are migrating a VB6 user control that works like an enhanced TextBox control. Such a control might includes a Text property that does nothing but wrapping the property with same name of the inner TextBox control:
Public Property Get Text() As String
Text = Text1.Text
End Property
Public Property Let Text(ByVal New_Text As String)
Text1.Text() = New_Text
PropertyChanged "Text"
End Property
This property is translated correctly, but it is clearly unnecessary under VB.NET and could be dropped without any negative impact on the migrated project. The simplest way to fix this code is by means of a couple of OutputMode pragmas:
Public Property Get Text() As String
Text = Text1.Text
End Property
Public Property Let Text(ByVal New_Text As String)
Text1.Text() = New_Text
PropertyChanged "Text"
End Property
You can use this technique to remove several common properties and methods, such as Visible, Enabled, BackColor, ForeColor, Value, Caption, and Refresh.
If you can’t remove a property – because it has no corresponding member in the base class – you can surely remove the annoying remark that the ActiveX Control Interface Wizard inserts before all properties, by means of a PostProcess pragma:
The ActiveX Control Interface Wizard generates a special comment for events, too:
Event Click()
Event KeyDown(KeyCode As Integer, Shift As Integer)
In the converted VB.NET application, the above lines become:
Public Shadows Event Click As VB6EventHandler
Public Shadows Event KeyDown As VB6KeyEventHandler
You can remove these comments appended to event declarations by means of another PostProcess pragma:
The Property Get procedure of properties that aren’t browsable in VB6 property window should test the Ambient.UserMode property and raise an error if it finds that the user control is running at design time:
Public Property Get SelText() As String
If Ambient.UserMode = False Then Err.Raise 387
SelText = Text1.SelText
End Property
VB Migration Partner interprets this statement correctly and marks the property as nonbrowsable, but doesn’t remove that statement:
<System.ComponentModel.Browsable(False)> _
<DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)> _
Public Property SelText() As String
Get
If Ambient.UserMode = False Then Err.Raise(387)
Return Text1.SelText
End Get
Set(ByVal New_SelText As String)
Text1.SelText = New_SelText
PropertyChanged("SelText")
CheckSelChange()
End Set
End Property
You can safely remove the statement yourself by means of yet another PostProcess pragma:
Notice that there are two spaces after the Then keyword.
Likewise, you can remove the call to the PropertyChanged method, which is useless under .NET, with another PostProcess pragma:
Finally, most public members of a user control are meant to be called by the client application and are never referenced from inside the user control class itself. For this reason, they will be flagged with the following warning:
You can avoid these warnings by means of the following pragma:
Note: VB Migration Partner comes with an extender named UserControl Polisher, which automatically performs all the tasks that here are implemented by means of PostProcess pragmas. We show how to reach the same result by means of pragmas, so that you can select which code elements you want to delete.