A C++ Screen Saver - Part 2

Written by Gordon Zeglinski

Introduction
It has been another fun-filled month battling with compilers. It got so annoying that I decided to reinstall VAC++ and give it a go after applying the latest CSDs it. While I was at it, I also reinstalled the SOMobjects Developer Toolkit and its 2.12 CSD. There's a huge improvement in VAC++ since I reviewed it last: the compiler and debugger are better, but the workframe and LPEX are still slow and bulky. Overall though, I was happy enough to continue with the DTS screen saver series started several issues ago.

In this column, we will continue with the development of the DTS screen saver. Step 1 is building a PM interface, and firming up the SOM screen saver member functions. Interestingly enough, moving from Metaware's DTS to VAC's DTS wasn't as painless as I thought.

DTS Is DTS Is DTS... Right?
Nope not at all. There's several changes needed to get the previous source code compiling under VAC. The first thing I noticed, was that the #pragma SOMAsDefault(on) didn't cause the SaverModule class to become a SOM object. OK, no big deal. We can switch to explicit SOM mode by deriving SaverModule from SOMObject directly. With these changes, we can now compile the DTS source into DLLs.

To create bindings for other languages, or to use DSOM, we must have an interface definition file (.IDL file), which the DTS compiler is responsible for generating. Here's where we have the most problems. Recall that in the TestSaver DTS Object there was a C++ member class. The Metaware compiler inserted some definitions into the .IDL file so that the SOM compiler (SC) would know Thread wasn't a native SOM type; VAC++ doesn't do this. So we have to manually add in these lines to the .IDL by using the SOMIDLPass pragma.

Well, our fun isn't over yet. Notice that TSTSAVE.HH includes SAVER.HH. One would naturally assume that TSTSAVE.IDL would include SAVER.IDL. That is not the case. Normally this wouldn't be a problem except when new types are defined in SAVER.HH that are used in TSTSAVE.HH. Thus, we have to add in the statement #include "saver.IDL" in TSTSAVE.IDL.

Enough bugs yet? Wait, there's one more. This time it's in SC. The type SaverModule::HWND is converted into a typedef unsigned long SaverModule__HWND statement in SAVER.IDL. How ever, when creating a C++ binding file (.XH file), the SaverModule__HWND type is not defined so we have to manually edit the file and insert the typedef ourselves. Finally we have everything "working." We can now look at the new .HH files. Below is the definition of SaverModule: Figure 1: SaverModule definition.

Deriving SaverModule from SOMObject, makes SaveModule a SOM Object. The concept of pure virtual functions map directly to reserved slots in the release order. Below we have the new definition of TestSaver. Note the definition created in the .IDL file by the #pragma SOMIDLPass statements were borrowed from the .IDL file created by the Metaware compiler. Figure 2: New version of TestSaver.

Now that we have the DTS stuff sorted out we can move on to the PM part.

On To PM
Because we're already using VAC++ for the DTS, let's go all the way and use VACs C++ windowing classes. Since this is the first attempt at putting everything into 1 program, we exercise the KISS ("Keep It Simple, Stupid") principle. A bare bones main window follows: Figure 3: Initial attempt at using IBM's OCL with DTS.

The class SaverMainWin is the main frame window. The class member myclient is a dialog window loaded from the resource template that acts as the client area for the main window. The class CommandHandler handles system commands (WM_SYSCOMMAND) for the main window and commands (WM_COMMAND) for the client window. As shown below, the constructor for SaverMainWin::CommandHandler registers itself as handling messages for the main window. Figure 4: Using the CommandHandler class.

The actual processing of the events occurs in two virtual functions. The member function systemCommand handles WM_SYSCOMMAND messages and command handles WM_COMMAND messages. The following code catches the system close message and then hides the main window. By returning false, the function insures that the default action is taken, which is to terminate the application. Figure 5: Intercepting WM_SYSCOMMAND messages.

When a button, menu item, or accelerator generate a command event, the command event's ID matches that of the item that generates the event. When the test button is pressed, a ButTest command event is generated. This event activates the screen saver. Pressing any other button results in the main window hiding itself. The following code does this task. Figure 6: Intercepting WM_COMMAND messages.

All the real action takes place in the SaverMainWin class. Its constructor creates the client window, a list box object, the event handler, and lastly creates an instance of the test screen saver. Figure 7: Initializing the SOM environment manually using VAC++'s flavour of DTS.

Thanks to the magic of encapsulation, our main routine is nice and small. Notice that unlike the MetaWare compiler, the SOM environment has to be explicitly initialized and deinitialized in the VAC. In the Metaware example, the SOM environment was implicitly created. Figure 8: Metaware's automatic initialization of the SOM environment.

Wrapping Things Up
That's about all the fun for this issue. Moving from Metaware to VAC's DTS wasn't as easy as I thought. A lot of time was spent figuring out why the VAC++ version crashed initially. We've seen how to use the basic features of IBM User Interface Class Library, and the ins and outs of using DTS in VAC++. Now that the initial hurdles have been cleared, the next issue will look at removing the hard-coded SOM saver class, and add some savers that do more than just display a message box.