---

2.7.5 SOM and OpenDoc

   OpenDoc is implemented as a class library defined as a set of SOM classes. 
   The classes are shown in Figure 45.  All OpenDoc parts are derived from 
   one abstract class ODPart, which has encapsulated all of the base methods 
   of a OpenDoc component, such as defining embedding, drag and drop, 
   linking, component activation and binding, basic frame behavior, 
   containment and user interface handling as shown in Figure 45. 


 


                                              



 
   Figure 45. OpenDoc Class Hierarchy 

   Some of the classes are part of the OpenDoc run-time environment and only 
   instantiated by OpenDoc; some of the classes are abstract classes, to be 
   used and overridden by components.  There are a couple of classes 
   available, derived from ODPart, that have already implemented many of the 
   base behavior for drag and drop, containment, linking and more. Many of 
   them are part of the OS/2 Toolkit or delivered with Partmeister as shown 
   in the example of "Sample IDL File Generated by Partmeister" in 
   topic 2.9.1, which is derived from IBM_Non_Container, a class drived from 
   ODPart. 

   A developer minimumly has to define how to store the data and how to 
   initialize a part handler with data already stored, and how to define the 
   way the view of the component is shown on the screen (see Figure 46). 


 


                                              



 
   Figure 46. OpenDoc ODPart 

   Components of an OpenDoc document share one OS/2 process.  This process is 
   called DocShell.  DocShell handles all functions that must be provided 
   across all the parts.  One reason that pieces of an application must be 
   redesigned when they are migrated to become part handler is due to the 
   fact that the resources of an OS/2 process are now shared between 
   different part handlers.  These resources such as windows, queues, 
   storage, and event handling, are normally owned exclusively by an 
   application .  OpenDoc is initializing this run-time environment by 
   instantiating a couple of OpenDoc classes.  The class relationships are 
   shown in Figure 47.  The root class that knows all references to the other 
   classes is ODSession, as shown in Figure 21 in topic 2.4. 


 


                                              



 
   Figure 47. OpenDoc Class Relationships 

   Another central class, as you can see in Figure 47, is ODStorageUnit which 
   is used from many any other classes such as drag/drop and clipboard.  The 
   GA Version of the OpenDoc Toolkit, which is included in the updated OS/2 
   Warp Developer Toolkit available from The Developer Connection for OS/2 
   Volume 9 Special Edition, also supports direct-to-SOM (DTS) component 
   development.  This enables developers to define and code their OpenDoc 
   parts directly in C++. The required IDL is then generated from Visual Age 
   C++ out of the C++ header files.  More details about the component 
   development can be found in the OpenDoc Programming Guide and Reference, 
   which is delivered with the updated IBM Developer's Toolkit for OS/2 Warp 
   Version 3, of The Developer Connection for OS/2 Volume 9 Special Edition. 
   A good starting point for component development is the samples provided 
   with the IBM Developer's Toolkit for OS/2 Warp Version 3. 

IBM BookManager® BookServer Copyright 1989, 1999 IBM Corporation. All rights reserved.