| Home | Previous Lesson: Scoping Variables Next Lesson: Displaying Popup Menu on the DataWindow |
When there are many objects in an application, you will probably want them to communicate, share variables and pass values among themselves. In a procedural programming language, it isn't a problem because, you either have one long program or a main routine with several subroutines and in the subroutine calls you pass the variables as parameters.
In an event-driven language, the process of communicating between objects is complex because of the fact that you don't always know what the user is going to do next. To make it easy, PowerBuilder provided us several different ways to communicate between its objects. We'll look at each of them, highlighting some of the pros and cons for each method.
As discussed in the previous section, a global variable can be accessed by any object in an application. This is the easiest way to pass values between objects, but as we've said before, they should be used sparingly.
Unless you adhere to a strict set of naming convention, global variables can cause problems when integrating modules developed by more than one development team. Another disadvantage is that they can be changed from anywhere in the application and since they exist throughout the duration of an application, you may not be using the memory efficiently.
Instance variables are declared at the object level and are considered as the attributes of the appropriate object. You can therefore refer an instance variable as any other attribute of an object.
// Standard window attribute w_product_master.visible = TRUE // Instance variable attribute // w_product_master.InstanceVarName = FALSE
Instance variables can be declared with different access levels ( We will be learning that in later sessions ). To refer an instance variable from another object, it must be declared as Public access. This is the default access level, so worry about it only if you change the access level. It is a good idea to restrict access to these instance variables by providing methods which act on them and allow other objects to access them through these methods only.
For windows, sheets and user objects, you can pass parameters by using
| OpenWithParm() | |
| OpenSheetWithParm() | |
| OpenUserObjectWithParm() |
functions, rather than just the standard plain old opening functions. If you are working with PowerBuilder windows, you can also return values by using the CloseWithReturn() function instead of the Close() function. The syntax for these functions are as follows:
OpenWithParm (<window name>, <parameter>, {Parent} )
The only disadvantage to this method is that you can only pass one parameter. We can get around this by using structures.
Structures are basically collections of variables/objects that are defined in the structure painter. If you know 'C' language, then think it as a structure in 'C' and if you are from 'COBOL' background, then think it as a record with no sub-levels.
To declare a structure, invoke the
structure painter by clicking on the
icon and define
the variable/object name and the datatype. The object can also be another PowerBuilder
structure. When you save a structure, it becomes a PowerBuilder object.
In functions like OpenWithParm(), you can pass only one parameter. Sometimes you may need to pass more than one parameter. If that is the case, use Structures. When you pass the Structure as the parameter, the opened object can access all members in the structure.
Till now we talked about sending parameters to the window while opening it, but, how does the opened window access those parameters? It is possible by the 'Message' object. When you use functions like OpenWithParm(), the parameter value is stored in a 'message' object. A 'message' object is a built-in global object that can be used as a carrier for the parameter. You can send one of the following data types through the 'message' object:
Data Type |
Stored in |
String |
Message.StringParm |
Numeric |
Message.DoubleParm |
PowerBuilder Object |
Message.PowerObjectParm |
The parameter is stored in the relevant 'message' object attribute, depending on the data type of the parameter. You can then refer to the parameter in the calling object by using the "Message." notation. For example:
// DataWindow
idw_2_save //Instance variable
idw_2_save = Message.PowerObjectParm
A possible problem associated with the 'message' object is that, all currently running applications can generate messages, so there is a chance of the 'message' object being overwritten.
A solution to this problem is, to declare an instance or local variable in the called object and then in the very first statement of the object's open event, assign this variable with the 'message' object attribute.
You can call functions declared in another object by using the following syntax:
<Object Name>.<Function Name> ( Parameter1, Parameter2, ...)
Keep in mind that, like instance variables, functions declared at the object level have an access level, so they must be declared as Public to be available to other objects.
Calling the TriggerEvent() or PostEvent() functions is a convenient way to execute the scripts of other windows or window control events. These functions allow you to write script in one place and execute them any number of times from other objects.
We've already used some of these methods of communication earlier in the session. We can't recommend any single method to be the best, as each have their own merits and can be used in many diverse circumstances. The advice we can give is, try various methods and find the one with which you feel comfortable.
| Home | Previous Lesson: Scoping Variables Next Lesson: Displaying Popup Menu on the DataWindow |