Tip #4 - Adding functionality to existing Power++ classes

In the past few months, I have run into several inquisitive customers asking how to add their own functionality to existing Power++ classes such as WString, WLong or WDataWindow. There are two approaches to this type of problem, depending on what type of class one wishes to extend.

Non-Visual Classes

I will deal with non-visual classes to begin with. As many of you may already know, C++ offers extended inheritance functionality and can be used to our advantage (in fact, almost all classes within Power++ take advantage of this). For those of you who have created a new class, then the screen to the right should be familiar; if not, this screen is accessed through the main Power++ menu by selecting File|New|Class.

When creating a new class with the Class Wizard, there is an Inherits from field, which always contains the default of public WObject. This field enables the user to specify an already existing class from which the new class will be derived (in other words, this specifies which existing classes the new class will inherit). Inheritance means that the newly created class contains all of the properties, methods, constructors and destructors that were declared as protected or public from the classes specified in the Inherits from field.

For example, if I specified public WString in the Inherits from field, then my new class would contain all of the methods, properties, constructors and destructors contained in the WString class. Consequently, any instance of my new class would contain a Length property (inherited from WString) and a ConvertToLong method identical to that from WString, along with all of its other components. Because WString is inherited, the creator of the new class does not need to worry about re-implementing any of its functionality, but only to add his or her customizations. Such customizations may be added in the same manner as a new property or method, without concern for the existing methods or properties, so long as the new items have unique names.

As an example of this, a developer might wish to capitalize the first letter in a WString and convert the rest to lower case. This could be easily done by adding a method to his new class called, for illustrational purposes, ConvertToName, since this type of capitalization conversion would suit a name perfectly. The method would look something like this:

WBool ConvertToName ( ) {
    WBool ret = ToUppercase ( Substring ( 0, 1 ) );
    ret = ret && ToLowercase ( Substring ( 1, GetLength ( ) - 2 ) );
    return ret;
}

Thus, if the developer had derived a class called NameString from WString, and added the above user function, he would be able to use it as follows:

NameString *name = new NameString ( "Doctor Power++" );
name->ConvertToName ( );

Visual Classes

Next we need to deal with adding functionality to a visual class. This presents a unique problem: each visual object is linked to a resource. A resource is a separate piece of information used by Windows to draw the object on the screen, and exists outside of our C++ code. When selecting a visual object from the component palette and dropping it on a form, Power++ automatically generates that object's resources, or links it to a pre-existing resources. By trying to create a new class that inherits from a visual class such as WDataWindow, the new class is not added to the Component Palette, and trying to create an instance of your new class with the new operator would not automatically generate the necessary resources.

As a result of the demand to be able to create custom visual objects in Power++, we have added an interim solution to version 1.5: in addition to creating a class which inherits from the desired visual object (as described above), the following steps must be performed.

Basically we've added a Class property to each component, accessible only through the property tab of the Object Inspector. Clicking on the ... for the property ( as seen above ) brings up a dialog that lets you specify two things: the name of the class that should be generated for the component and the names of any header files to automatically include when the component is added to a form ( seen at right ). The design environment will not do anything else with these values - they only affect the code that is generated for your application.

Here's a more concrete example of what it does and how you'd use it. Say you want to add a couple of business rules (some actions you commonly perform, via new methods) to a DataWindow. First you'd drop a DataWindow onto your form as you normally would. If you ran the application at this point and looked at the generated source code, what you'd see is something like this: 

class __Form1_Base : public WDialog {
....
private:
WDataWindow *dw_1;
....
};
 
WBool __Form1_Base::__Base_Create()
{
....
dw_1 = new WDataWindow;
....
} 

Now you go to your Classes view and add a new class called MyDataWindow that inherits from WDataWindow. You define your business rules, etc. in there just as you would any C++ class (i.e., add all of your required methods and properties). Now you head back to the DW on your form, open the property inspector and choose the Class property to bring up the special dialog. For the class name you would type MyDataWindow and for the header files you would type wdatawin.hpp and MyDataWindow.hpp. Now you rebuild your application. The code that gets generated now looks like: 

#include "wdatawin.hpp"
#include "MyDataWindow.hpp"
 
class __Form1_Base : public WDialog {
....
private:
MyDataWindow *dw_1;
....
};
 
WBool __Form1_Base::__Base_Create()
{
....
dw_1 = new MyDataWindow;
....
} 

It's almost the same as before, except that the reference to WDataWindow was replaced with MyDataWindow. The design environment still thinks it's dealing with a WDataWindow object and so you can set all the normal properties and events, but at runtime your code (your constructor, any of the virtual functions you've overridden, etc.) gets run. 

This is not meant to be a complete solution for component building. Power++ 2.0 will come with complete visual component building abilities.

Click here to see Tip#5

Return to Power++ Home Page.

to top of page

---

Sybase HomeSearchContact UsCorporate InformationPress ReleasesProductsShop OnlinePartnersTechnical SupportConsultingEducationSolutionsSuccess StoriesEventsDownloadsInternational Sites/Offices

Copyright © 1999 Sybase, Inc. All Rights Reserved.
Privacy Policy
Legal