Extend Statement Summary
Extend is a nonterminal, refactoring statement that occurs only in
hostid oriented
Refactor
statements. Its purpose is to add properties to control classes needed to process property bag code. It can
also be used to mirror coclasses in libraries.
The attributes of the
Extend statement are as follows:
Attribute | Description
|
Id | This attribute is the identifier of the class or coclass which is the focus of the extend operation.
It is expressed relative to the Id attribute of the parent Refactor statement. It must
identify a class or coclass within the hosting library.
|
The substatements of the
Extend statement are as follows:
Substatement | Description
|
Property | A declaration statement that declares a property to be added to the class identified by the statement.
Any valid Property declaration may used.
|
Coclass | A terminal substatement of the Extend statement that extends the library with a new coclass
with a different Id but with the same subclasses.
|
The script errors associated with the
Extend statement are as follows:
Error | Description
|
1101 | Extend identifier [%1d] is not defined.
|
The primary use of
Extend is to add properties to control classes to satisfy references in the form property bag
specification. By default the
gmBasic VB6 property bag processor assumes that the names included with
BeginProperty statements and on the left-hand-side of
name=value are the names of properties of the
containing control class. In the absence of any additional specification, when the processor encounters a name that
it cannot identifier it triggers an "UndefinedProperty"condition. The
Select UndefinedProperties attribute
is used to control the treatment of this condition. Consider, for example, a simple code using the unmigrated
mscomctl.ocx set of controls with
undefinedproperties="warn".
WARNING#5403: Filename <\ImageList\vb6\Form1.frm>
Property <NumButtons> not recognized
Record: NumButtons= 5
WARNING#5403: Filename <\ImageList\vb6\Form1.frm>
Property <Images> not recognized
Record: BeginProperty Images {2C247F25-8591-11D1-B16A-00C0F0283628}
Regardless of whether a warning is issued or ignored the statement or the property block for undefined properties
is then skipped. Assuming that skipping these specifications is not desirable the simplest way to deal with them is
to simply add the missing properties to the relevant control class. Since the identifiers are not defined, there will
be no references to them in the real code, so no harm is done. The refactoring
Extend statement adds properties
to a control. As an example
<Extend id="IImageList" >
<Property id="Images" type="ListImages" />
</Extend>
<Extend id="IToolbar" >
<Property id="NumButtons" type="integer" />
</Extend>
The
id attribute is the identifier of the class that is to be extended. It can be fully-qualified in the
same manner as other identifiers within a refactoring specification. Even here great care must be taken. Properties
are contained in classes, while controls in OCX's are usually coclasses, which contain multiple classes.
The
Property statements themselves are completely standard. The properties added with the
Extend statement
behave exactly like the original ones and can be referenced later by other refactoring statements and migclasses.
Coclass Extend Substatement Summary
Coclass is a terminal substatement of the
Extend statement. It can be used if and only if the
Id
attribute of the parent
Extend identifies a coclass. The statement adds a second coclass to the host library
with the same subclasses as the host coclass but with a different identifier.
The attributes of the
Coclass substatement are as follows:
Attribute | Description
|
Id | This attribute is the identifier of a new coclass to be added to the parent library that will match
the host coclass.
|
As an example, instances of the
Button coclass of the
MSCOMCTL.OCX can be migrated to either to .NET
ToolStripButton or
ToolStripSeparator. The actual choice depends upon the properties of the
instance, but the first step is to create a second coclass
Separator that can be used to anchor the new
references. Assuming that the original declaration of
Button was
<coclass id="Button" creatable="off" role="control" >
<subclass id="IButton"/>
</coclass>
Then this refactoring statement
<Extend id="Button" >
<Coclass id="Separator" />
</Extend>
does the same thing as adding this declaration to the original reference script
<coclass id="Separator" creatable="off" role="control" >
<subclass id="IButton"/>
</coclass>