Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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>


Table of Contents

  • No labels