The ability to define resources such as window and dialog templates externally to the application, in conjunction with the dynamic linking facilities provided by the OS/2 operating system, provides a powerful tool for the creation of generic application objects, comprised of window/dialog templates and their associated window or dialog procedures. These application objects may be defined and stored in dynamic link libraries for subsequent use by one or more applications. This practice is in accordance with the guidelines for Systems Application Architecture Common Applications, which provide for common application services within and between environments, as well as common user applications. This concept is further discussed in Generic Application Modules. Note however, that the use of generic application objects presupposes that the nature of and message interfaces to such application objects are well-defined and documented, in order to allow application developers to correctly select and interact with the generic objects.
For instance, a standard dialog box that will be used by many applications could be defined in a dialog template, resource compiled and stored in a dynamic link library, along with the dialog procedure which performs the processing for that dialog. The dialog can then be loaded from the DLL by any application which needs to use it. The dialog need be coded only once, and may be modified at any time while requiring no source code changes to the applications that access it. The fact that DLL code is not bound with the application at link edit time like other library code also means that no changes are required to the object code of the applications, and thus recompilation and link edit is not required. An example of this technique is given in Presentation Manager Resources.
The window or dialog procedure associated with a generic object should contain all the methods normally used to perform actions upon that object, but need not contain every action that will ever be necessary. If an application requires a specialized action on a generic object (that is, a previously undefined action or a modification of an existing action), the window acting as a handle to that object may be subclassed, and a new window procedure substituted for the existing window procedure. This new window procedure would contain methods to process the specific messages in which it has an interest, and would then invoke the original window procedure to handle any other message classes, in accordance with the object-oriented principle of inheritance. Subclassing is discussed further in Subclassing.