Why was CB designed as it is - benefits to programmer?

[Gary Beene]

There seems to be some duplication in the CB functions, and I'd like to understand what drove the design decision. I'd guess there's some benefit to PB programmers, but other than common nomenclature within a message response, I'm not sure what it is.

In both %WM_NOTIFY and %WM_COMMAND, the wParam value contains:
control ID Lo(Word, CB.wparam)
notification msg Hi(Word, CB.lparam)

The only difference between the two messages is in lParam.

%WM_NOTIFY lParam contains pointer to NMHDR structure
%WM_COMMAND lParam contains handle of control sending the message

But in both %WM_NOTIFY and %WM_COMMAND, these commands are valid (even though both are discussed only under %WM_COMMAND).

CB.CTL control ID
CB.CTLMSG notification message

Then, in %WM_NOTIFY, PB offers the following CB values:
CB.NMHWND control handle
CB.NMID control ID
CB.NMCODE notification message

It looks like cb.ctl and cb.nmid are duplicate functions. It also looks like cb.ctlmsg and cb.nmcode are duplicate functions. And all are available in both %ws_notify and %ws_command messages.

Is there a benefit to using cb.ctl over cb.nmid? Or using cb.ctlmsg over cb.nmcode? Or any other reason why the duplicate functions needed to be maintained?

[Michael Mattias]

It looks like cb.ctl and cb.nmid are duplicate functions. It also looks like cb.ctlmsg and cb.nmcode are duplicate functions. And all are available in both %ws_notify and %ws_command message

Re-read MS documentation for WM_COMMAND and WM_NOTIFY, paying particular attention to the remarks under WM_NOTIFY regarding the correct way to obtain the control ID and notification code.

[Gary Beene]

Yes, I read that.

But in the case of %ws_notify, PB help didn't state where they got CB.CTL and CB.CTLMSG from. They do say they got it from wParam for %ws_command. But they don't say where it comes from for %ws_notify.

One might think they'd read MSDN too and would get the info appropriately from the nmhdr structure when the message was %ws_notify, whereas getting it from wParam is fine when the message was %ws_command.

However, your implied assumption that they took it from wParam (for %ws_notify) would seem logical. Help just doesn't tell me for sure.

I guess I'd have to ask them to know for sure.

[Gary Beene]

Michael,

I also noticed that in the Samples distributed with PowerBASIC, the cb.ctl function is sometimes used when %ws_notify messages are trapped.

So if you're correct in assuming that cb.ctl is always derived from wParam, then the Samples carry the risk mentioned at MSDN.

[Michael Mattias]

There is lots of stuff help does not tell you "for sure." But that's been my experience with PB products since 1991.

But in this case, "how they get it" is not only proprietary, it is immaterial.

PB guarantees the CB.* system variables contain certain things based on the message ID.

Either they do and everyone is happy, or they don't and you have a bug report to file.

MCM

[Michael Mattias]

Samples distributed with PowerBASIC, the cb.ctl function is sometimes used when %ws_notify messages are trapped.

Those would be officially known as...... "really bad samples."

There's also some "really bad samples" in the help file. When it's in the help file, then it's a bug. The help files are a warranted part of the product; the samples are not.

MCM

[Chris Boss]

Previous versions of PB only supported passing the WM_COMMAND notification messages to control callback functions.

The CB functions were intially defined for that.

In PB 9.0, the WM_NOTIFY notification messages were added to the DDT engine, being forwarded to the control callback.

WM_NOTIFY process is critical to handling the common controls.

Now, the decision was obviously made to not overlap the two message handlers, WM_COMMAND and WM_NOTIFY.

There are pros and cons to this, the none the less, the decision was made to treat the two messages separately.

This means the CB function has versions for WM_COMMAND (which are backward compatible with previous versions of PB) and then new versions were added specific to WM_NOTIFY.

In once sense, this makes sense, because technically you are handling two different message handlers in one callback function. This will make sure you keep your coding between the two types of message handlers separate, even though in one function.

You should always determine first whether the notification message is coming through WM_COMMAND or WM_NOTIFY. The PB docs explain how to do this. Then the WM_COMMAND code should be parsed out separately from the WM_NOTIFY code.

There really isn't any duplication here, since each message handler is different and there are two sets of CB functions, one for each handler (WM_COMMAND or WM_NOTIFY).

Also it should be noted the new syntax for the CB functions:

ie.

CB.LPARAM

rather than

CBLPARAM (no period)

I think this was a good idea, since it helps you appreciate that DDT uses one function CB to store a structure of data (multiple data fields). The new systnax is similiar to what is used for TYPEs, which is quite accurate.