Troubleshooting Applications Upgraded from Visual Basic 6.0
Although the upgrading tools in Visual Basic 2005 are carefully designed to detect and report any issues with upgraded applications, there are some cases that cannot possibly be detected. This page lists some known issues that are not detected by the upgrading tools and explains how to address them.
When working with an application upgraded with an earlier version of Visual Studio, the Help links inserted by the upgrade tool may cause a "Page not found" error. This occurs because the links reference the Help collection for the earlier version, and the format for the Help links have changed.
To fix this problem, you can copy the error string and use the Search function in Help to find the topic. Note that some error strings include variables, so you may need to search on a partial string.
In Visual Basic 6.0, strings assigned to a fixed-length string in a user-defined type are automatically truncated if they are longer than the fixed length. After upgrading to Visual Basic 2005, strings are no longer truncated, possibly resulting in incorrect results.
During upgrade, the VBFixedString attribute is added to fixed-length strings in user-defined types. This attribute allows the file functions in the Visual Basic Compatibility library to treat them as fixed-length strings.
To fix this problem, find any code that assigns a string to the fixed-length string and add code to check the length of the string and truncate it if necessary:
In Visual Basic 6.0, you can unload a form and later reload it by calling the Show method. In Visual Basic 2005, the Close method for a form calls the Dispose method so that it is automatically garbage-collected. This can cause subtle behavioral differences that may be hard to detect.
In Visual Basic 2005, if you call the Show method for a form that has been unloaded, you will get a new instance of the form; any property settings from the base class will be lost.
For forms that are shown modally, Dispose is not called automatically. In some cases, you may want to call Dispose in order to clean up resources.
In Visual Basic 6.0, when a late-bound COM object is passed as a parameter to a late-bound call, the object is coerced to a Variant of type Nothing. When upgraded to Visual Basic 2005, COM objects declared as type Object are treated the same as Variants (which are always converted to type Object during upgrade); these objects are marshaled to the variant type Empty. This causes a type mismatch error in Visual Basic 2005.
To fix this problem, make sure that all objects are early bound.
In some cases, errors returned by Visual Basic 2005 may be different than those returned by Visual Basic 6.0. For error handling code that relied on the values returned by Err.Number, this might cause different behavior in your application.
The following code shows an example of this:
' Visual Basic 6.0 On Local Error GoTo Result Dim x() As Boolean Dim y As Variant y = x(10) Result: If Err.Number = 9 Then ' Do something. Else ' Do something else. End If
Before upgrading, Err.Number will always return 9 (Subscript out of range) and execute the first part of the If statement. After upgrading, it will return 91 (Object variable or With block not set) and execute the Else clause. This is because in Visual Basic 2005, an array must be initialized before it can be referenced; in Visual Basic 6.0, arrays are initialized when declared.
If you depend on the return values from Err.Number in your code, you should carefully test the results and modify your code as necessary.