|Statement||Description of use|
|Refactor||Introduces a set of refactoring statements|
|CallByName||Changes symbol-related code events that yield CallByName late binding calls into direct boxed calls.|
|Extend||Extends the content of a class by adding new components.|
|FixType||Changes the binary type of a component or group of components|
|Generic||Specifies that individual subprogram parameters be implemented as being generic to accept a list of different types.|
|Implements||Specifies that a VB6 class implements another class or interface.|
|MigClass||Introduces a new class that contains related refactoring information used for complex migration operations, especially as related to designer code.|
|Migrate||Specifies migration of a specific symbol introduced via an external library description.|
|OverGeneric||Specifies that individual subprogram parameters be implemented as being generic in an overloaded method to accept a list of different types.|
|Overload||Specifies that individual subprogram arguments be overloaded to accept a list of different types.|
|Reauthor||Replaces the content of a subprogram with a completely rewritten block of code|
|Remove||Prevents a component from being authored|
|Rename||Changes the authored name of components|
|Replace||Replaces either the members of an external class or the patterns of opcodes via replacement declarations.|
Refactoring tends to effect the entire code base. It is not intended to make individual changes in actual code. The source code fixing operations are intended for this. The rule of thumb for using a refactoring operation as opposed to a fix editing operation is that the specification for the final recipient of the change is a symbol as opposed to a line/block of code. In general, portation is an art and the selection of which approach to use will clearly vary by individual and application.
Whenever possible, refactoring should be done via "shallow" changes -- changes which are applied to the actual surface or source form of the code using the Fix statement. These shallow changes can be applied to both the source code before it is translated and to the target code after it is produced, but before it is published. Such changes are easy to visualize and to specify. Unfortunately many of the changes needed cannot be specified in this way -- refactoring is required.
Begin VB.Form VB0001Form Caption = "VB0001" ClientHeight = 5115 ClientLeft = 60 ClientTop = 345 ClientWidth = 5280 LinkTopic = "Form1" ScaleHeight = 5115 ScaleWidth = 5280 StartUpPosition = 3 'Windows Default Begin VB.CommandButton Command1 Caption = "Run VB0001 Test" Height = 375 Left = 1440 TabIndex = 0 Top = 1320 Width = 1935 End End
There are of course properties of controls that are themselves object types rather than simple value types. The most common of these is the Font property. Here is an example of a specification of this type.
Begin VB.Label lblFirst Alignment = 2 'Center BorderStyle = 1 'Fixed Single Caption = "VB is fun" BeginProperty Font Name = "MS Sans Serif" Size = 24 Charset = 0 Weight = 700 Underline = 0 'False Italic = 0 'False Strikethrough = 0 'False EndProperty Height = 615 Left = 2040 TabIndex = 0 Top = 480 Width = 2655 End
All of the above is an oversimplification in every possible way. Even in the above "simplest of all examples", for example, the VB.Label control type does not have a property called Font; rather it has properties like FontName, FontSize etc. When the above syntax is extended to COM CONTROLS all formal relationships are ignored in every possible way. The specifications look like the above, but there truly are no real rules. Each COM property specification has to be examined carefully and converted into a specification that associates values with a set of user-defined controls in a consistent manner.
Converting the input property specifications into a consistent form is a difficult, but trivial problem when compared to the problem of reauthoring those specifications in .NET. The two primary problems are that in .NET controls are not nested, they have a linear structure and then there are later instructions that add children into the scope of the parents. How and when and with what adornments are needed to make these scope specifications vary widely. In addition in .NET some values are assigned to properties directly in the code and others are assigned via external resource files.
An important point to be remembered about the property specification code is that though it uses opcodes, though opcodes are not authored via a string-machine. It has code fragments in it that can be evaluated and viewed in the same way as procedural code, but it is used simply as a data-store for the information initially obtained from the VB6 specifications and then as changed to supply information to the .NET control author. New properties must be added, old properties must be removed or restructured or radically migrated. There are no dependable simplistic correspondences between properties defined for the classes and references to those properties. The goal is that the eventual authored .NET property specifications will accurately reflect the original intent of the VB6 source; however, that goal is achieved via the interaction of diverse components and not directly in the property code blocks.