In the former case, the communication is quite simple since the initiator of the communication typically has knowledge of the type of object to which the communication is being passed, and can usually initiate the communication by simply invoking a method in the receiving object, in a similar manner to that discussed in Methods (Invoking Another Object's Methods).
However, it is often necessary to determine the identity of the object for which a method must be invoked. The Workplace Shell provides access to objects using the HOBJECT and the OBJECTID and, at a base level, system object model provides pointers to objects and SOM IDs. Each of these is described in the following sections, and some discussion is included on converting between identifiers.
HOBJECT
This identifier is the object handle, which is allocated by the Workplace Shell and passed as the return value from the WinCreateObject() function. It is a persistent object handle that remains allocated to an object for the duration of its existence. Object handles persist across system restarts, and may therefore be used by one object to refer to another object at any time.
An object handle can be determined from the object's OBJECTID using the WinQueryObject() function, as follows:
HOBJECT hObject; /* Object handle */ PSZ szObjectID = "<OBJECTID>"; /* OBJECTID string */ hObject = WinQueryObject(szObjectID); /* Query object handle */
Note that this function may be called from any process; its use is not restricted to objects in the Workplace Shell process.
OBJECTID
The OBJECTID is provided by an application or object class as part of the setup string parameter in the WinCreateObject() call, when an object is created. It is persistent in the same way as an object handle, but provides a more meaningful reference for an object, which can be used by other objects.
Figure "Referencing an Object Using OBJECTID"
Note that the angle brackets ("<" and ">") used within the OBJECTID are an important part of the syntax.
Note also that the Workplace Shell provides a number of predefined OBJECTIDs for system-defined objects. The first and third WinCreateObject() calls in Figure "Referencing an Object Using OBJECTID" use the <WP_DESKTOP> OBJECTID to place the objects on the desktop.
SOM Pointer
SOM pointers come in various forms, but can all be typecast to SOMAny *. From a Workplace Shell perspective, a SOM pointer is the return value of the _wpclsNew class method; this is the method used for creating objects within the Workplace Shell process. An object's public methods and data can be accessed using the object's SOM pointer.
A SOM pointer for an object may be obtained from an object handle using the _wpclsQueryObject method provided by the WPObject class, as follows:
SOMAny *Asomptr; /* SOM pointers */
SOMAny *Bsomptr;
Asomptr = _wpclsQueryObject(_WPObject, /* Query SOM pointer */
hObject); /* Object handle */
A SOM pointer for a class may be obtained from the SOM ID for that class, using the _somFindClass method shown below:
Asomptr = _somFindClass(SOMClassMgrObject,
AsomId,
1,
1);
A SOM pointer for a class may be obtained from the SOM pointer for any object within that class, using the _somGetClass method as follows:
Asomptr = _somGetClass(Bsomptr);
The SOM pointer is typically used to invoke class methods from an object in another class. The _SOMDispatchL() method shown in Figure "Invoking a Method in Another Object Class" requires a SOM pointer as a parameter.
SOM ID
A SOM ID is simply a way of mapping a unique number to a string. This string may represent the name of a method or class. SOM IDs are integers that are managed by the Workplace Shell using the Atom Manager facility of Presentation Manager. A SOM ID is obtained using the SOM_IdFromString() function as follows:
somId AsomId;
AsomId = SOM_IdFromString("WPFolder");
The SOM ID is typically used to obtain a SOM pointer, which can then be used to invoke a method.