Object Packages
An object package is a package that creates an object. As you start to assemble an application, you will find that you are placing a group of objects together. A normal application will need an error object, a help object, a confirm object, and a number of view objects. You will usually only need one of each of these objects.
The object packages allow you to pick the objects you need and place them in your program with use statements. It is our goal that object packages be so independent that they can be written and tested stand-alone and then included in any program with the knowledge that they will work with any combination of other object packages. In order for this to work, object packages must be completely encapsulated and must have a simple and well-defined interface. Package objects will very often reside at the desktop level. Package objects often need to be available to all other objects in a program. Some of these objects can be placed at the desktop making them available to all objects. Other objects (usually visual ones) are placed within your main panel object.
Some object packages are provided with DataFlex (the help, error, and confirm object packages). Most object packages you will create yourself. Typically, you will create list-object packages and view-object packages. When you create an object package, you want to place everything in that package required to make it work. Because of this, an object package will often use class packages and other object packages.
The use command does not re-include any package that has previously been included in the program. You might have five views that all need the same list-object package and data-server class package. You would include these packages in all views. When the views are compiled and tested stand-alone, all packages will get included and your test program will run. When the five views are added to a single program, any packages that were included in more than one of the test programs will only get included once in the final program.
It is very important that object packages provide a simple, defined access method to their objects. In many cases, there will only be one way to access a package object. Lookup-list object packages provide a single access message, the message popup (e.g., Send popup to oMy_List). This should be the only message you ever send to the lookup list. All you need to know is the message name and the object name. This allows the programmer in charge of the object (the "owner" of the object package) to make any changes needed in the object.
Unlike class packages, it is not expected that you can extend object packages without changing the package's code. It is also not expected that the provided object packages will act exactly as you wish. For example, the confirm package (DfConfrm.pkg) displays a number of prompts whose text may not be to your liking. You should feel free to create your own object packages (using the provided object packages as a template). You will not, however, want to change the package's access methods (e.g., the save-a-record confirmation must always be accessed with the save_confirmation message).