Built-in objects
App
VB.NET doesn’t directly support the App object. However, most of its properties
can be mapped to members of the My.Application object, as indicated below:
Comments: My.Application.Info.Description
CompanyName: My.Application.Info.CompanyName
ExeName: My.Application.Info.AssemblyName
FileDescription: My.Application.Info.Title
LegalCopywright: My.Application.Info.Copywright
LegalTrademarks: My.Application.Info.Trademark
Major: My.Application.Info.Version.Major
Minor: My.Application.Info.Version.Minor
Path: My.Application.Info.DirectoryPath
ProductName: My.Application.Info.ProductName
Revision: My.Application.Info.Version.Build
Title: My.Application.Info.Title
The Title property is read-write in VB6 and readonly in VB.NET.
A few properties can be rendered by means of specific methods in the .NET Framework:
The hInstance VB6 property corresponds to the Process.GetCurrentProcess().Id
method.
The ThreadID VB6 property corresponds to AppDomain.GetCurrentThreadID()
methods; however, notice that the GetCurrentThreadID method has been obsoleted in
.NET 2.0 because it doesn’t account for cases when the current application
runs on a lightweight thread (a.k.a. fibers). More more info, see
http://go.microsoft.com/fwlink/?linkid=14202.
A few App members are used to log application events - namely the LogMode
and LogPath properties and the StartLogging and
LogEvent methods. These members have no direct counterparts in
the .NET Framework. The simplest way to implement logging to file or the Windows
log is by means of the methods and properties of My.Application.Log object.
The PrevInstance property has no direct equivalent under the .NET
Framework. However, VB.NET notifies you when the current application is the second
instance of another (already running) application by firing the StartupNextInstance
event. You could then use this event to initialize a global variable to True
Public App_PrevInstance = False
Private Sub MyApplication_StartupNextInstance(ByVal sender As Object, _
ByVal e As Microsoft.VisualBasic.ApplicationServices.StartupNextInstanceEventArgs) _
Handles Me.StartupNextInstance
App_PrevInstance = True
End Sub
For VB.NET to fire the StartupNextInstance event, it is required that the application
be marked as a single-instance application, in the Application tab of the My Project
page.
A few properties have no meaning under the .NET Framework, therefore they can be
treated as constant values (or just ignored) under VB.NET:
HelpFile: VB.NET doesn’t offer an automatic mechanism for
implementing help, therefore this property is meaningless under .NET and can be
ignored.
NonModalAllowed: the .NET Framework never prevents modeless windows,
therefore this property can be assumed to always return True under VB.NET.
OleRequestPending* and OleServerBusy* properties:
.NET apps can never receive an OleRequestPending or an OleServerBusy error, therefore
all these properties can be safely ignored under VB.NET.
RetainedProject: the .NET doesn’t support the notion of retained
projects, hence this property can be assumed to be always equal to False under VB.NET.
StartMode: the .NET Framework doesn’t support ActiveX EXE
application, therefore this property is always equal to 0-vbSModeStandalone for
EXE projects or equal to 1-vsSModeAutomation for DLL projects.
TaskVisible: the .NET Framework doesn’t offer a straightforward
way to hide an application from the Task Manager, therefore this property should
be considered to be equal to True and nonwritable under VB.NET.
UnattendedApp: .NET doesn’t have a property that corresponds
to this, therefore this property should be always considered as equal to False.
VB Migration Partner translates the App object to the App6 object;
all properties and methods are supported, including all those related to event logging.
A few members behave slightly differently from VB6, for the reasons explained above.
VB Migration Partner ignores assignments to the Title property, or throws a runtime
error if VB6Config.ThrowOnUnsupportedMembers property is set to
True. Under VB.NET you can change the text displayed in the Task Manager for the
current application by changing the main window’s Text property.
Clipboard
The VB6 Clipboard object corresponds to the My.Computer.Clipboard objects. There is a one-to-one correspondence for most methods, except the GetFormat method corresponds to the ContainsData .NET method; the enumerated type used for the argument is different.
VB Migration Partner translates the Clipboard object to the Clipboard6 object; all properties and methods are supported, including minor details and quirks.
Collection
VB.NET fully supports the Collection object (defined in Microsoft.VisualBasic namespace) and the Upgrade Wizard correctly converts references to this type.
You can often improve the performance of migrated code by replacing the Collection object with one of the types defined in the System.Collection namespace, for example the ArrayList or HashTable objects. If the collection holds items of same type, you can also use the strong-typed List(Of T) or Dictionary(Of T) types, defined in the System.Collection.Generic namespace.
The main issue with these .NET objects is that none of them supports all the features of the VB6 Collection, for example the ability to reference an item both using a string key and its positional index.
Like the Upgrade Wizard, VB Migration Partner migrates references to the Collection object using the .NET Microsoft.VisualBasic.Collection type. However, you can optionally map the Collection object to the more powerful VB6Collection type, which gives you the same high performance as the .NET native objects while supporting all the features of the VB6 object. For more information read this blog post.
DataEnvironment
The .NET Framework doesn’t support the DataEnvironment object or any other objects that resembles the DataEnvironment object. The Upgrade Wizard converts these classes by generating the code for a class that inherit from the BaseDataEnvironment type defined in the Microsoft.VisualBasic.Compatibility.Data assembly. However, the translation isn’t always perfect. For example, the Name property isn’t supported and the Upgrade Wizard fails to automatically converts default properties in some cases. For example, if a DataEnvironment class exposes a method named AuthorsByState which takes a string argument, then the following statement:
DataEnvironment1.AuthorsByState txtState
isn't migrated correctly because the Upgrade Wizard fails to append the default Text property to the txtState reference.
VB Migration Partner follows the same approach as the Upgrade Wizard, except the generated class inherits from the VB6DataEnvironment class defined in VB Migration Partner’s support library. Unlike the Upgrade Wizard, all the DataEnvironment members are fully supported, as is the generation of default properties.
DataObject
The VB6 DataObject is used in drag-and-drop scenarios and holds that data taken from the source control and about to be dropped on the target control. VB6 and VB.NET implement drag-and-drop in completely different and incompatible ways, therefore the Upgrade Wizard doesn’t convert this object.
VB Migration Partner fully supports OLE drag-and-drop properties, methods, and events, and maps the DataObject type to the VB6DataObject type defined in VB Migration Partner’s support library. All DataObject members are supported, including the ability to store file names when dragging elements from Windows Explorer.
Forms
The VB6 Forms collection broadly corresponds to the OpenForms collection of the System.Windows.Forms.Application object. However, there is an important difference: the VB6 Form collection includes all loaded forms, whereas the VB.NET OpenForms collection includes only the forms that are currently visible. This difference implies that the number of items in the Forms and OpenForms collection can be different, which makes quite hard to correctly translate the following VB6 code:
For n = Forms.Count - 1 To 0 Step -1
Unload Forms(n)
Next
In fact, if you translate this code to VB.NET using the OpenForms collection, the forms that are loaded but not visible won’t be unloaded, thus preventing the current application from terminating as expecting.
VB Migration Partner translates the Forms collection to the Forms6 collection; as in VB6, the Forms6 collection contains all the loaded forms, be them visible or hidden.
LicenseInfo and Licenses
The .NET Framework supports a licensing mechanism that is completely different from the VB6 mechanism, hence VB.NET doesn’t support the LicenseInfo object and the Licenses collection.
VB Migration Partner does support these objects and all its members. Converted VB.NET code therefore create a LicenseInfo object and add it to (or remove it from) the Licenses collection. However, the LicenseInfo object does nothing and its only purpose is to avoid compilation errors in migrated projects.
Printer and Printers
The VB6 Printer object and the Printers collection don’t directly correspond to any .NET Framework object. The Upgrade Wizard 2008 manages to do the conversion by mapping these objects to the Printer and Printers objects defined in the Visual Basic Power Pack library. However, the Printer object in the Visual Basic Power Pack library lacks a few members of the VB6 object, namely the DrawMode, DeviceName, hDC, Port, and Zoom properties
VB Migration Partner converts references to the Printer object and the Printers collection using the Printer6 and Printers6 types defined in the support library. All members are supported and no dependency from the Visual Basic Power Pack library is introduced.
PropertyBag
VB.NET doesn’t support the PropertyBag object. The Upgrade Wizard doesn’t migrate statements that use this object. You can simulate this object by writing data into a MemoryStream objects and then use its GetBuffer method to read the stream contents as a Byte array. You can even serialize entire object trees, provided that all the objects in the tree are marked with the Serializable attribute.
VB Migration Partner fully supports the PropertyBag object and its ReadProperty, WriteProperty, and Contents members.
Screen
The VB6 Screen object broadly corresponds to the System.Windows.Forms.Screen .NET object, however a few members must be mapped to different properties and methods of the .NET Framework.
The TwipsPerPixelX and TwipsPerPixelY properties can be translated using methods defined in the Microsoft.VisualBasic.Compatibility assembly:
twipsPerPixelX = Microsoft.VisualBasic.Compatibility.VB6.Support.PixelsToTwipsX(1)
twipsPerPixelY = Microsoft.VisualBasic.Compatibility.VB6.Support.PixelsToTwipsY(1)
The Width and Height properties can be rendered by means of the Bounds property of the Screen object, as in:
width = System.Windows.Forms.Screen.PrimaryScreen.Bounds.Width
height = System.Windows.Forms.Screen.PrimaryScreen.Bounds.Height
Notice that the Bounds object’s properties return values in pixels, therefore you should multiply the result by TwipsPerPixelX or TwipsPerPixelY to get the number of twips.
The Fonts collection and the FontCount property can be approximately rendered under VB.NET by means of the Families member the System.Drawing.FontFamily object:
fonts = System.Drawing.FontFamily.Families
fontCount = System.Drawing.FontFamily.Families.Length
The ActiveForm property has no direct .NET counterpart. Under VB.NET you can find the current form by iterating over the OpenForms collection until you find the form that has the input focus:
For Each frm As Form In Application.OpenForms
If frm.ContainsFocus Then activeForm = frm: Exit For
Next
If the application is an MDI application, you can retrieve the active MDI child form as follows:
activeForm = MdiForm.ActiveMdiChild
The ActiveControl property has no direct .NET counterpart. You can simulate the Screen.ActiveControl property by searching for the active form first (see above) and then querying the ActiveControl property of the active form.
The MousePointer and MouseIcon properties have no direct .NET counterpart. You can simulate the Screen.MousePointer property by searching for the active form first (see above) and then querying the Cursor property of the active form.
VB Migration Partner translates the Screen object to the Screen6 object. All properties and methods are supported, with just one limitation: the MouseIcon property always returns Nothing; attempts to assign it a non-Nothing value are ignored or raise an exception if the VB6Config.ThrowOnUnsupportedMembers property is set to True.
VBControlExtender
Under VB6 this object is typically used in conjunction with the Controls.Add method, because it gives access to a number of Extender properties (e.g. Container, Enabled, Left, Top, HelpContextID, and others), methods (Move, SetFocus, ZOrders) and events (GotFocus, LostFocus, Validate. Another important feature of the VBControlExtender object is the ability to handle events in late-bound mode, thanks to its ObjectEvent event.
The Upgrade Wizard doesn’t support the Controls.Add method and attempts to converts the VBControlExtender object using the System.Windows.Forms.AxHost type. However, the AxHost type lacks many of the members originally exposed by VBControlExtender, including anything comparable to ObjectEvent. Worse, the AxHost object can hold only references to ActiveX controls, therefore you can’t use it when dynamically adding a standard .NET control.
VB Migration Partner fully supports the Controls.Add method, the VBControlExtender type and all its members, including the ObjectEvent event. A VBControlExtender object can be associated with both a standard .NET control or an ActiveX control.