We have a common PBL (common.pbl) that is used by three different applications. Each application declares some global variables of types of user objects in the common PBL.
Objects in the common PBL need access to some of those same global variables, so our design was that they get injected into the objects with of_initialize functions (for user objects) or as PowerObjectParms with OpenWithParm for windows.
So for instance one of the global variables that instantiates a common PBL object is called gMsg (a custom messagebox). To inject it into a window in the common PBL, we would OpenWithParm(windowName, gMsg), and in the window, declare an instance variable iMsg of the same type, and in the Open event, do iMsg = Message.PowerObjectParm. Then whenever we need that in that window, just use iMsg.
We did that because we compile the common PBL separately (so each app doesn't always have to do so), using a separate tiny common application PBL (commonapp.pbl). The application object common.sra in commonapp.pbl doesn’t contain declarations of the same global variables. So commonapp.pbl and common.pbl together wouldn't compile if any objects in common.pbl referred directly to the main applications' global variables.
Then we use only common.pbd, compiled as above, in each of the three real applications. (Commonapp.pbl is only used for the separate compilation of common.pbl.)
But it just occurred to me that I can declare global variables in common.sra using the same names and data types as the individual application's application objects do - such as gMsg mentioned above. Then all other objects in commonapp.pbl could just refer to the global variables by their normal names, and it would work whether for compiling commonapp.pbl along with common.pbl separately, or when using common.pbd as part of the actual applications.
Does anyone see any problem with this change, like reasons why the global variables with the same names in the application object in commonapp.pbl and the real applications' application objects would not be seen as being the same?
Thanks.
The question I asked (which basically nobody has answered, preferring to offer their philosophies on the use of global variables, which I did not ask for!) is whether using those same global variables in the shared PBL, which is usually used as a PBD, will cause any problems, as long as we declare the same variables in the application object of the small PBL we use for compiling the shared one.
If anyone has specific answers about that actual question I asked I would be glad to hear them. As I have said in one previous reply, a very minimal test of such a change seems to have worked fine, but I'm looking for your knowledge about whether there's anything I'm missing that would cause it not to work (outside of philosophical objections).
Thank you.
I wouldn't convert existing code that works fine. Code that remains static has less risk of sudden failure than code often modified.
My learnings with PowerScript >
A) IF - your shared .PBD code references any global variable - THEN - Keep "globals" list identical (types + order) across apps to increase success rate. - PERIOD.
B) "Globals" = 5 x standard global (SQLCA, etc) + your explicit global variables. Every app defines the standard variables before first "global variable" so type difference in any standard variable may alter memory positions of your explicit globals and render your shared .PBD erroneous in at least one app.
My recommendations >
1) Keep your shared .PBD as independent of any globals as practically feasible to minimize risk when reusing.
2) Inject references to any global as function arguments -- EX: Pass SQLCA as argument to a setter for an instance variable.
3) Avoid direct access to Message object's properties in your shared .PBD.
4) Test for safe .PBD sharing before any code release.
You may have less inherent risk in your app port folio than I often see. I still recommend dependency injection to globals dependency.
Mitigate any such risk by keeping shared .PBD code self-contained and avoid duplicate names for classes and DW objects.
HTH /Michael