Cubus Known Bugs

OIP_Socket.hpp memory leak

OIP_Socket::~OIP_Socket()
{
 close();
 if (phost) delete phost;        // I added this (confirmed by Benno)
}

OVioException.hpp

error EDC3013: "a" is undefined.
error EDC3013: "b" is undefined.
error EDC3013: "c" is undefined.

#define OThrowVio    (a, b, c) (throw OVioException(a, b, c, __FILE__, __LINE__))

                ^^^^

Spaces cause errors with CSet++ v2.1

Fix:

#define OThrowVio(a, b, c) (throw OVioException(a, b, c, __FILE__, __LINE__))

Benno Patch

Latest patches from Benno: ocl150p1.zip

ODate.CPP
OStatusLine.CPP
OXcptBase.CPP

These files should replace the older ones from the last OCL Release.

I patched ODate as suggested by Reinhard Schuerer to fix the bug in ODate::asString
I fixed the "bug" mentioned by Phil in OXcptBase :-))
I implemented some cosmetics to OStatusLine (3D-style)

Simply replace the files and recompile the libraries.

OCL News - the mailing list for OCL users

Notice about oxcptbase.cpp

This isn't a bug, I just happened to notice it:

From oxcptbase.cpp "Acknowleged" below is missing the 'w'

  case XCPT_SIGNAL:
    msg << "Acknoledged signal: ";

ODate Class Bug

I found a few bugs in the ODate class concerning the ODate::asString function. I included a diffs file of my patches to correct the bugs.

202c202 < fmt.getText()[3] = fmt.getText()[6] = ctryInfo.szDateSeparator[0]; ---

> fmt.getText()[2] = fmt.getText()[5] = ctryInfo.szDateSeparator[0]; 212c212,213 < OString result(((fmt != NULL) ? strlen(fmt) : 0) + 3); --- > int iLength = ((fmt != NULL) ? strlen(fmt) : 0) + 3; > OString result(iLength); 226c227 < strftime((PSZ)result, result.length(), fmt, &dummy); --- > strftime((PSZ)result, iLength, fmt, &dummy);

Reinhard --

        |                
    ___ |__      
   /    |  |          Reinhard Schuerer 
   |___ |  |          TEAM OS/2

error L2029: 'OList<unsigned long>::operator<<(unsigned long*) : unresolved external

Q: When I try to link a PM program with OMenu and ocli.lib, LINK386

   gives L2029 errrors from OMenu.cpp.

A: Add the following to one of your source files:

   #pragma define (OList<ULONG>)

   and recompile. This should work.

BOOL OContainerBase::setEmphasis(PVOID record, ULONG emphasis, BOOL set)

BOOL OContainerBase::setEmphasis(PVOID record, ULONG emphasis, BOOL set) const {

return((BOOL)WinSendMsg(hwnd, 
                        CM_SETRECORDEMPHASIS, 
                        MPFROMP(record),

                                   This

                        MPFROM2SHORT(emphasis, set)));

                               Should be this
                               
                        MPFROM2SHORT(set, emphasis)));

}

Subject: how to respond to HM_QUERY_KEYS_HELP

Q: I am adding help to my application and I have a question about OHelp and BOOL OCommand(ULONG msg, ...).

If I call helpRequest(OHelp::keys), this causes HM_QUERY_KEYS_HELP to be sent to the window procedure.

When I receive HM_QUERY_KEYS_HELP, I am supposed to return the panel res to be displayed.

If OCommand() is a BOOL, how can I return the proper help id panel?

A: Add the following code to OWinDefWindow.cpp in funtion OWinDefWindowProc

      case HM_QUERY_KEYS_HELP:
        return(MRESULT(OApp::OCMDTrace(hwnd, msg, mp1, mp2)));

and then return in your OCommand-member-function:

      case HM_QUERY_KEYS_HELP:
        return((BOOL)keyPanelID);

This is a hack. But it should work because for the OCL BOOL is defined as int.

This workaround will be included in the next release of the OCL.