Author Topic: A clock in WPS - Educational Project  (Read 757 times)

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Thank You
  • -Given: 469
  • -Receive: 95
  • Posts: 2656
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: A clock in WPS - Educational Project
« Reply #15 on: May 23, 2020, 11:16:23 pm »

sc.exe compiler worked and generated me the CPP, XH and XIH files.

Now I want to compile it (icc.exe), but no luck yet. I tried to make a basic make file based on HWman, but Im still clueless. (file inside the attachment)
What command and arguments do you recommend to compile this exercise?

The other thing that Im clueless is how to reference the resource GUI files (3 screens) with the three methods, so it can be displayed once the class is registered and the object created.

« Last Edit: May 23, 2020, 11:36:25 pm by Martin Iturbide »
Martin Iturbide
OS2World NewsMaster
... just share the dream.


  • Hero Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 51
  • Posts: 552
    • View Profile
Re: A clock in WPS - Educational Project
« Reply #16 on: May 24, 2020, 10:23:55 am »
1) do not specify -D__IBMC__ when calling the compiler. That defeats the whole purpose of compiling C++ code as this define is set when the C-compiler is run but not the C++.compiler

2) you are now entering into the dark realms of SOM programming. What you are missing in particular is to include <os2.h> in your code (and defining the proper defines INCL_BASE and INCL_PM) because even the generated code refers to datatypes that are defined in the OS/2 include files.
You could now do this in two ways:
#define INCL_BASE
#define INCL_PM
#include <os2.h>
in your c++ source file, even before including "xwpclock.xih". That is easy but is has the negative impact that you have to do that manually and it might get acidentally removed by sc.exe.
you add some "instrumentation" in your .idl file that tells sc.exe to automatically generate these statements into your c++ source file:
        passthru C_xh_before = ""
        "#define INCL_PM"
        "#define INCL_BASE"
        "#include <os2.h>"
That will place these statements into xwpclock.xh (at the correct place) which is included by xwpclock.xih.
You will have to read the SOM programming documentation to understand what's going on, hint: "xih" is the implementation header which is used by the guy implementing the class, "xh" is the public definition header used by the guy using the class in his own code and the guy implementing the class.

3) in your .rc file you misspelled the . h file you intend to include. Therefore you will get an error on building

4) in your .h file you missed to define DLG_XWPCLOCKTIME and possibly others. The resource compiler gives a bogus warning because it thinks that identifier is a string (where it should be the define for a number)

5) when you actually want to use resources (like a dialog), you will need to query the module handle of your own DLL because that module handle will need to be passed to OS/2 API functions creating dialogs (like WinLoadDlg etc.) and then to specify the ID of the resource/dialog, like DLG_XWPCLOCKALARM. In order to do that you will need to include the xwpclock-resources.h not only in your .rc file but also in the c++ source file. Again, you can hack that in manually or have it done via the .idl file.

6) There are multiple ways to query your own module handle: you either write a custom _DLL_InitTerm function to get to the handle (which is the most forward way for me, but maybe not to others,see the hwman sample code) or you can use SOM method "somLocateClassFile" plus OS/2 API function "DosGetModuleHandle" to get to the module handle:

HMODULE gModule = NULLHANDLE; /* needs to be placed somewhere into the data segent and NOT on the stack ! */

somId theId = somIdFromString("XWPClock");
ModName = SOMClassMgr->somLocateClassFile(theId,XWPClock_MajorVersion,XWPClock_MinorVersion); /* you need to include <somcm.xh> */
DosQueryModuleHandle(ModName,&gModule); /* gModule now contains your module handle */

It should be obvious to you that you will need to fix this piece of code once you change your class name to something else. Maybe you now see why I always go for the custom _DLL_InitTerm function ...

« Last Edit: May 24, 2020, 10:42:09 am by Lars »