The sample creates and opens a new folder on the Desktop, and then inserts a number of different class objects into that folder, one of which is opened after it is created. It also creates and deletes an abstract object on the Desktop before terminating.
Note: The sample uses the four new functions that are available for manipulating the daemon and the server:
This sample Workplace Shell DSOM program demonstrates the minimum Workplace Shell code required to initialize a simple Workplace Shell DSOM application. To ensure that it will always run, regardless of the current state of the DSOM server, the sample queries and saves the state of both the DSOM daemon and the Workplace Shell DSOM server. The state is saved, so that it can be reset before the program terminates.
Once the server is active, a local DSOM environment is created by calling SOM_CreateLocalEnvironment and then register itself with the DSOM daemon by calling SOMD_Init. Before any Workplace Shell method calls can be made, the Workplace Shell class manager must be merged with the SOM's class manager, and then Workplace Shell classes on which method calls will be made must be initialized. For instance, if you are writing an application that creates an abstract object on the Desktop and then terminates, both WPObjectNewClass and WPAbstractNewClass would need to be called because WPAbstract is a descendant of WPObject.
Next a server must be located to execute the methods on, so _somdFindServerByName is called to find the Workplace Shell DSOM server wpdServer. To query the Desktop object, first the class object for WPFolder must be acquired by calling _somdGetClassObj. With this pointer, finally the first Workplace Shell method _wpclsQueryFolder is called to acquire a pointer to the Desktop folder. Once the pointer to the Desktop folder is obtained, objects are created using _wpclsNew. As soon as the folder object on the Desktop is created, it uses that object pointer as the target for all the other objects created. A Details view of the folder is created using _wpSetup and the new created color palette is opened with a call to _wpOpen. The abstract object created on the Desktop is finally destroyed with a call to _wpDelete.
Before terminating, the DSOM environment should be cleaned up by calling the reverse of initialization:
The sample also resets the state of the DSOM daemon and Workplace Shell DSOM server before terminating. In other words, if the server was active when the sample application was run, then it will remain active when it terminates. If on the other hand it was not running, then it will be stopped before the program terminates. This may not be the desired result in most applications. If you are running a number of DSOM client applications back to back, then you will not want ythe application stopping the server each time. In most cases, you should leave the server active after it is started.