...
Overview
This content has not yet been reauthored as a WIKI page, Please refer to this PDF:
Control Replacement Primer
Upgrading a control has three types of work:
1) upgrading the object model and members in logic
Good news is that this is the same as upgrading a standard (i.e. non-control) API
You will typically name the replacement control in the coClass a the bottom of the IDF. For example:
Code Block |
---|
...
<coclass id="fpText" migName="System.Windows.Forms.RichTextBox" migStatus="External" role="control">
<subclass id="IfpText"/>
<subclass id="_DfpText"/>
</coclass>
<coclass id="fpMask" migName="System.Windows.Forms.MaskedTextBox" migStatus="External" role="control">
<subclass id="IfpMask"/>
<subclass id="_DfpMask"/>
</coclass>
<coclass id="fpDateTime" migName="RadDateTimePicker" role="control">
<subclass id="IfpDateTime"/>
<subclass id="_DfpDateTime"/>
</coclass>
<coclass id="fpDoubleSingle" migName="System.Windows.Forms.NumericUpDown" migStatus="External" role="control">
<subclass id="IfpDoubleSingle"/>
<subclass id="_DfpDoubleSingle"/>
</coclass>
<coclass id="fpLongInteger" migName="System.Windows.Forms.NumericUpDown" migStatus="External" role="control">
<subclass id="IfpLongInteger"/>
<subclass id="_DfpLongInteger"/>
</coclass>
|
Notice that adding role=control is needed to make sure the objects are added to their parent containers
If a control is being migrated to a component, do not use role=control
2) upgrading event handlers
- event arg types
- event name changes
- event handler arguiments -- these are statements added to the event handler to setup the old style event args as local variables in the handler.
Code Block |
---|
<event id="ItemClick" netName="ItemClick" migStatus="mscomctl" role="event"
netHandler="System.Windows.Forms.ListViewItemSelectionChangedEventHandler"
netArgs="ListViewItemSelectionChangedEventArgs" migPattern="ItemSelectionChanged" >
<argument id="item" type="ListItem" status="ByVal" migPattern="%1d = e.Item" />
</event> |
3) Designer code -- property initialization
- these are specifications for what properties to set in teh designer.cs code file adn how to set them
Code Block |
---|
<!--
**********************************************************
* Statusbar Designer Code
**********************************************************
-->
<migClass id="NetControl.StatusBar"
migName="System.Windows.Forms.StatusStrip"
parent="StatusBar"
>
<property id="Font" value="Font" type="FontInfo"
nPram="3"
vbnPattern="New System.Drawing.Font(\s%1d\s, %2d!, %3d, System.Drawing.GraphicsUnit.Point, CType(0,Byte))"
cshPattern="new System.Drawing.Font(\s%1d\s, %2dF, %3d, System.Drawing.GraphicsUnit.Point, (System.Byte)(0))"
/>
<property id="Location"
value="(Left,Top)"
nPram="2"
vbnPattern="New System.Drawing.Point(%1d, %2d)"
cshPattern="new System.Drawing.Point(%1d, %2d)"
/>
<property id="Name" type="string"
value="SYM.name"
/>
<property id="Size"
value="(Width,Height)"
nPram="2"
vbnPattern="New System.Drawing.Size(%1d, %2d)"
cshPattern="new System.Drawing.Size(%1d, %2d)"
/>
<property id="TabIndex" type="Integer"
value="TabIndex"
default="0"
/>
</migClass>
|
Setting a color property in the designer
Code Block |
---|
<migClass id="NetControl.fpDoubleSingle" migName="NumericUpDown" parent="fpDoubleSingle">
<property id="BackColor" type="OLE_COLOR"
value="IfpDoubleSingle.BackColor"
nPram="3"
migPattern="System.Drawing.Color.FromArgb(%3d, %2d, %1d)"
default="System.Drawing.SystemColors.WindowText"
/> |
...
gmStudio has an Open Type System that allows us to recognize, interpret, store, and express information about how VB6/ASP codes use COM APIs. This includes both third-party COM APIs and controls and COM APIs and controls defined by your VB6 codes.
Our type system allows users to specify rules that adjust how the type system works includes
- defining custom types,
- enhancing the legacy COM API's object model, and
- mapping COM API to various .NET replacements.
These rules may be
- declarative using an XML notation,
- implemented using our scripting language, and
- implemented using our C# API.
gmStudio's open, extensible capability for COM API replacement is arguably the most powerful feature of our platform.
Additional Reading
- ComponentReplacement.pdf describes the COM upgrade methodology with examples (This content is in a PDF and not yet been reauthored as a WIKI page)
- Using RefactorLibraries Files for COM API replacement describes using RefactorLibrary files as a means of specifying COM replacements
- Support Statement: Stub Replacement describes how the tool uses support framework generation to as an initial step in COM replacements
- Author Interface Description Files describes how to generate COM API descriptions for consumption by the translator
- Incremental Upgrade Cookbook describes how to move incrementally upgrade from a local COM framework to a global on
- Samples is a high level article describing our samples. Many of these demonstrate COM API and control replacements
- gmStudio Extensions is a catalog of COM API replacement rules (and other goodies) to assist with upgrade development