#413 winsystm.cls

Mark Miesfeld
Lee Peedin

All classes within winsystm.cls are sub-classes of WindowsClassesBase "except" the WindowObject class. This means that if any calls are made to the WindowObject class the user must explicitly load the external functions.

These functions will be loaded automatically if the WindowObject class is made a subclass of WindowsClassesBase AND the init method of the WindowObject class is changed to:
::method Init
use arg hwnd
forward class (super) continue
self~hwnd = hwnd
return self~InitCode

In the same light the init method of the MenuObject class should be changed to:
use arg hwnd, main
forward class (super) continue
self~hwnd = hwnd
self~MainWnd = main
return self~InitCode

(it is already a subclass of WindowObject)


  • Mark Miesfeld
    Mark Miesfeld

    Logged In: YES
    Originator: NO

    After reviewing the code, it seems that the original designers probably did not expect the WindowObject to ever be instantiated when it wasn't used in the same context as a WindowsManager object. In general a WindowObject would always be instantiated by a WindowsManager.

    You can not use a WindowObject unless you get a valid window handle from the underlying Windows API. At this time, the only real way to do this in ooRexx is through the WindowsManager or through ooDialog. ooDialog has all the neccessary methods to work with the Windows API, so the programmer does not need to use a WindowObject when working with ooDialog.

    Because of the reference counting that the WindowsClassesBase does, there is not a clear cut code change that could help the situation.

    The best solution seems to be updating the docs so that when programmers do use the WindowObject outside of the context of a WindowsManger, the know to ensure that the C functions are loaded. This can easily be done by simply instantiating a WindowsManager object. The object does not need to be use.

    The docs have been updated to reflect this.

    Committed revision 962.



Cancel   Add attachments