Advanced PowerBuilder

Polymorphism - PB Implementation

PowerBuilder allows you to implement polymorphism in two ways:

	Sending Messages.
	Function Overloading.
	Function Overriding.

PowerBuilder itself implements all of these in the PowerClass. Let's look at each method one after the other.

Sending Messages

If you look at the PowerBuilder system class hierarchy, you'll see that PictureButton control is inherited from the CommandButton control. This makes sense, as both perform the same function.

Whenever you click a CommandButton, the script for the clicked event is executed; the same is true for a PictureButton. Since both are in the same polymorphic family, there is no need to call different event names for each of them. They can have the same event, but execute different script. This is polymorphism in practice - the same event is called in both cases, but the script that is to be executed is passed like a parameter to the executing function, depending on the control being clicked.

Function Overloading

Function overloading allows you to use the same function name to get different sets of results/behavior from the script. PowerBuilder allows this flexibility by responding to the parameters that are sent with the function call.

As an example of how function overloading works, let's look at PowerBuilder's MessageBox() function. This function allows you to output to the screen, via a dialog box, a string, a numeric or a boolean value. Usually, you would need to develop three nearly identical scripts to handle this functionality, but by using function overloading you can achieve the same result with only little effort.

The compiler identifies the version of the function to use depending on one of the arguments that must be passed to it, which in this case is the text parameter. This allows you to use a small function set, with great range of functionality. The disadvantage is its run-time overhead.  Each time the function is called, the compiler has to find the appropriate function, depending on the arguments passed.

In PowerBuilder, function overloading can be done in two ways: inheritance or external functions. With version 5.0, you can overload the function without using inheritance.

Function Overloading Using Inheritance

If you want to use inheritance to allow function overloading, you must complete two basic tasks:

1	Define a base class that contains the basic definition of the function.
2	Define another class by inheriting from the base class and alter the function definition in the descendent class to reflect the required overloading.

By performing these steps, you produce two similarly named functions, that share a relationship, and which are organized into a predefined structure, that PowerBuilder understands and can use it when a call to this function name is received. PowerBuilder looks for the appropriate function in the entire object hierarchy, starting from the current level and working towards the top, until it finds the first appropriate version of the function.

Function Overloading without using Inheritance

With version 5.0, you can define multiple functions with the same name and with different arguments, at the same object level. This reduces the overhead, because, there is no need to use complex inheritance hierarchy for one function overloading. Let us take the same example of  MessageBox()function. You see multiple MessageBox() functions definition at the same object level, i.e., "systemfunctions" class. In prior versions, PowerSoft did the same thing, but didn't allow it for the developers. With version 5.0, developers are allowed to do the same. Other examples would be  TriggerEvent(), PostEvent() defined at "PowerObject".

However, it is not allowed if you try to overload the function just because the return data type is different.

Function Overriding

You can define the same function at different levels of the inheritance hierarchy tree. For example, you can define a save() at the base window, and can define the same function in the master and transaction windows,  inherited from the base window. Now, you can write different script in the save() in the master window and the save() in the transaction window. This is because, PowerBuilder looks for the function from the current object level to up; calling the function in the master window always executes the logic written in the master window save function.

For example, suppose you have three objects A, B and C in a hierarchy, where A is at the top and B is inherited from it. If you declared a function in A that prints a message to the printer, B inherits it. By modifying this function, you can set up your overloaded function too, say, print out a message in Times New Roman, rather than the default font.

If you now call this function from C, the function declared at B will be executed, causing the specified message to appear at your printer in Times New Roman, rather than the default font defined at A.

Home	Previous Lesson: Polymorphism Next Lesson: PowerBuilder's Class Hierarchy