Understanding Message - better questions this time

[Gary Beene]

Having digested help from folks on an earlier post, I'm hoping responses to this post will finally clarify a few concepts for me.

Reading MSDN, there are sections for the various windows (windows, dialogs, menus, and common controls). There are also sections for various system/hardware objects (cursor, mouse, keyboard, timers, keyboard, gdi, clipboard, shell - and others).

In both, there can be two listings - "Notifications" and "Messages".

Since MSDN states that controls send notification messages to their parent windows, is it correct that all entries in the "Notifications" lists for controls can be trapped in PowerBASIC callback functions - in both the control and dialog callback functions?

But if the control "Notifications" are sent to the parent window (PB dialog), why are they visible in the control callback? Is this a feature of the dialog class window procedure, to pass "Notifications" to the callback function for the control from which the "Notification" was sent - as a matter of convenience in sorting them out?

There are also non-window (non-control) objects listed at MSDN, which have "Notifications" lists. I assume these "Notifications" are sent from the objects to the affected windows (controls or dialogs, in the case of PB apps) and all of these can also be trapped in the control and dialog callback functions in a PB app?

Are there any items in the "Notifications" lists (for windows/dialogs/controls or system/hardware objects) which cannot be trapped by a PB control or dialog callback function?

Finally, is it the case that the MSDN lists titled "Messages" contain messages to which the windows/objects (where the list is given) can respond? And that it is this list of messages to which sublcassing gives access?

And really finally, is it the case that all "Notifications" and "Messages" can be sent by a PB app using SendMessage API or the DDT COntrol Send statement. No exceptions?

[Michael Mattias]

But if the control "Notifications" are sent to the parent window (PB dialog), why are they visible in the control callback?

Why? Because of the proprietary methods used by PowerBASIC Inc. to support its equally-proprietary "Dynamic Dialog Tools" offering, that's why.

And really finally, is it the case that all "Notifications" and "Messages" can be sent by a PB app using SendMessage API or the DDT CONTROL SEND statement. No exceptions?

Well, the programmer never SENDS "notifications", the programmer REACTS to notifications. The programmer sends messages to "do something."

But if you want to get kind of syntax-anal, "notifications" are provided in the form of messages sent by the operating system to the window (dialog) procedure.

SendMessage () can be used regardless of coding style; CONTROL SEND may only be used for controls added using CONTROL ADD to a dialog created with DIALOG NEW, and only from within the code module in which the DIALOG NEW and CONTROL ADD statements were executed.

(Although last time I looked CONTROL SEND will work on non-DDT dialogs, it is not supported and you do so at your own risk).

MCM

[Edwin Knoppert]

>Well, the programmer never SENDS "notifications",
I write custom controls and send notification messages to the parent window usually as WM_NOTIFY message and often a custom NMHDR type.

[Gary Beene]

You stated:

Well, the programmer never SENDS "notifications"

Wouldn't this fit under the category of sending a "notification"?

from PowerBASIC help...
*Programmatically post a click message to a button:
*CONTROL POST hDlg, %ID_BTN1, %BN_CLICK, 0, 0

[Chris Boss]

Yes, all notification messages can be processed in the parent windows dialog (or window) procedure. Thats why they are called notifications.

DDT's control callback functions are not "Windows callback" functions, but are simply a unique and powerful method for handling notification messages using DDT.

The two main notification message handlers are:

WM_COMMAND
WM_NOTIFY

These "handler" messages can pass all sorts of class specific (control specific) notification messages (sub messages is probably a better term) from controls to the parent window or dialog.

Now DDT does a neat "trick".

Rather than have to write all your notification processing code in the parent dialog's dialog procedure, DDT forwards the WM_COMMAND and WM_NOTIFY messages to functions you define, unique for each control.

It just makes things easier, rather than you writing all your own functions and having to call them from the parent dialogs dialog procedure.

DDT takes advantage of a nice feature of WM_COMMAND and WM_NOTIFY.

Both messages pass a consistant format of data in wparam and lparam so you can always derive the child controls ID or Handle. Since these are always there, DDT can easilly parse out the message and determine which control callback routine should get the notification message.

It surely makes for better and easier coding when working with controls.

Forget all the "warnings" about it being proprietary and not pure SDK.

DDT's control callbacks are simply the compiler forwarding notification messages to the appropriate function (for each control), rather than you having to write all the forwarded code in the parent dialogs dialog procedure.

DDT also puts some of the data from those notification messages into the CB functions of the compilers language.

ie.

wparam

becomes

CB.WPARAM

now thats easy enough!

Msg

becomes

CB.MSG

get it ?

DDT is a very well thought out "shortcut" to API programming, which produces simpler and cleaner code.

[Chris Boss]

Just a little more explanation about Notification messages:

Notification messages are not Window messages which you process like other window messages (ie. WM_SIZE, WM_MOVE).

A better term would be they are:

Sub Messages (nothing to do with subroutine)

or

Child Messages

Notification messages require a parent handler Message.

The two most common are:

WM_COMMAND
WM_NOTIFY

These two are real window messages, which can be processed in a dialog or window procedure.

Now the parameters (wParam and lParam) that these two messages pass with them, contain Sub (or Child) messages within them. By parsing out the parameters, you can determine the ID or handle of the control sending the message and a unique class specific (control specific) notification message value.

So when dealing with notification messages, don't think in terms of a window message, like other messages, but simply think in terms of notification messages simply being a parameter of another message (like WM_COMMAND).

Also notification messages are unique to each window class (control type), which is why they all have some prefix in the name to match the control class.

Button notification messages start with:

BN_

Edit control notification messages start with:

EN_

Listview notification messages start with:

LVN_

get it ?

The API docs will tell you whether the notification message is passed via WM_COMMAND or WM_NOTIFY.

The common controls normally use WM_NOTIFY
The standard controls normally use WM_COMMAND

Some controls use both, like the richedit.

[Michael Mattias]

Wouldn't this fit under the category of sending a "notification"?
from PowerBASIC help...

*Programmatically post a click message to a button:

  CONTROL POST hDlg, %ID_BTN1, %BN_CLICK, 0, 0

Nope.

The notification is the WM_COMMAND/BN_CLICKED notification message generated by the operating system when the button processes the %BN_CLICK message sent to it.

MCM

[Chris Boss]

Michael is correct.

Note my explanation above about notification messages actually no being window messages but are simply child messages which are passed as parameters to actual window messages (WM_COMMAND or WM_NOTIFY) which I refer to as message handlers (they handle child notification messages).

There are two levels of messages here.

One is window messages (ie. WM_COMMAND)

and

child messages passed through a window message as parameters, which is what notification messages are.

A common mistake made by new PB users, is to use a notification like a window message in CONTROL SEND. Notification messages are never passed as the MSG parameter of CONTROL send. They must have a parent message handler (ie. WM_NOTIFY) and they will be in either the wparam or lparam parameters of the message, either as a value or as part of the data in a structure passed in the parameter (ie. NMHDR structure).

[Michael Mattias]

>Well, the programmer never SENDS "notifications",
I write custom controls and send notification messages to the parent window usually as WM_NOTIFY message and often a custom NMHDR type.

The programmer using your control does not "send notifications." Using a custom control should be - to the programmer - just like using a button or label or edit control: it's a 'black box' which is made to do things by sending it a message, or tells you something of importance has happened by sending you a notification.

My contention would be, if the programmer is in a position to generate a notification, he does not need to, because he is perforce already aware of whatever it is for which it would be worth generating a notification!

MCM

[Fred Harris]

Of course, I'm working on developing a reputation for doing 'frowned upon' things, but I do occasionally (quite infrequently, really) find uses for sending notification messages. Below is a subclass procedure that hooks all the buttons on an SDK window. The user can navigate among the controls on the Window by using either the [ENTER] key or the [TAB] key. However, if the user hits the [ENTER] key when the 'Calculate' button has the focus, I create a WM_COMMAND message with the BN_CLICKED in the WParam.

i.e.,

MakDwd(%IDC_CALCULATE,%BN_CLICKED)

Of course, the program has an event procedure for BN_CLICKED,

Sub cmdCalculate_Click(Wea As WndEventArgs).

which I could have just called directly instead I guess. But nonetheless I think its a nice thing to know how to do.

Function fnNewButtonProc(ByVal hWnd As Long,ByVal wMsg As Long,ByVal wParam As Long,ByVal lParam As Long) As Long
  If wMsg=%WM_CHAR Then
     Select Case As Long LoWrd(wParam)
       Case %VK_TAB
         If GetDlgCtrlID(hWnd) = %IDC_CALCULATE Then
            Call SetFocus(GetDlgItem(GetParent(hWnd),%IDC_AREA))
         End If
         If GetDlgCtrlID(hWnd) = %IDC_CLEAR Then
            Call SetFocus(GetDlgItem(GetParent(hWnd),%IDC_LENGTH))
         End If
       Case %VK_RETURN
         If GetDlgCtrlID(hWnd) = %IDC_CALCULATE Then
            SendMessage(GetParent(hWnd),%WM_COMMAND,MakDwd(%IDC_CALCULATE,%BN_CLICKED),GetDlgItem(hWnd,%IDC_CALCULATE))
            Call SetFocus(GetDlgItem(GetParent(hWnd),%IDC_CLEAR))
         End If
         If GetDlgCtrlID(hWnd) = %IDC_CLEAR Then
            SendMessage(GetParent(hWnd),%WM_COMMAND,MakDwd(%IDC_CLEAR,%BN_CLICKED),GetDlgItem(hWnd,%IDC_CLEAR))
            Call SetFocus(GetDlgItem(GetParent(hWnd),%IDC_LENGTH))
         End If
     End Select
  End If

  fnNewButtonProc=CallWindowProc(fnOldButtonProc,hWnd,wMsg,wParam,lParam)
End Function

[Michael Mattias]

but I do occasionally (quite infrequently, really) find uses for sending notification messages.

... you code is not unreasonable at all... frankly I think it's an excellent plan of attack.

When you think about what you are doing, you are not really 'sending a notification' so much as you are 'doing something in response to a notification'.... that notification being, "user pressed the tab key." Arranging for your program code which handles this to be in one place seems sound design.

I tend to think of notification messages as being that which is provided in response to events you do not directly control.. e.g something the user [of this program] did or some kind of operating system event such as WM_TIMECHANGE or WM_SETTINGCHANGE

[Walt Decker]

TO: Gary Beene

If you really want to get a handle on things, find a copy of "Programming Windows 95" by Charles Petzold. Go through that and absorb what he's writing. A good way to make the connection between SDK style and PBDDT style is translate his supplied code to DDT.

[Steve Rossell]

You will find the sample code from "Programming Windows" by Petzold converted to PowerBASIC For Windows code on the PowerBASIC Downloads page.

[Walt Decker]

You will find the sample code from "Programming Windows" by Petzold converted to PowerBASIC For Windows code on the PowerBASIC Downloads page.

Sure. But looking at that isn't nearly as informative as reading the book and doing it yourself.

[Gary Beene]

Walt/Steve,

Thanks for the comment. I've looked locally, with no success. Guess I'll have to visit Amazon later today.

[Fred Harris]

Petzold

I've been following your slow progress in putting the pieces all together concerning learning PowerBASIC for some time Gary, and I do recall a number of times different folks have recommended to you to get a copy of one of Petzold's 'Programming Windows' books, as Walt above just mentioned again. Frankly, I'm amazed you have not done so yet at this point. That book is indispensible, as, from Webster, 'not subject to being set aside or neglected; absolutely necessary'. You can get a copy of his Windows 95 book likely for little more than the cost of postage & handling.

PS

Just checked. Quite a few copies for $ 0.01; however $1.99 will buy you a copy with a CD!

http://www.amazon.com/gp/offer-listi...889226&sr=8-16

[Gary Beene]

Hi Fred,

Actually, learning to create apps isn't particularly difficult with PowerBASIC. The issue that I whine about is how much a new-to-PB programmer has to take on faith (that what I don't know isn't a big problem). I'm a RTM-before-I-install-the-software kind of guy and what I've had to do with PowerBASIC is essentially piece-meal learning - from multiple sources. The idea that I have to go outside PB documentation to learn to be good at PB is mind-boggling to someone used to Microsoft languages and their ton of documentation. When I learn a new fact, I like it to fit into the "big picture" before I decide to use the fact. That's the real slowndown for me - I wait to learn 10 things before I use 1.

Despite any whines I might have, I must admit I'm having a lot of fun with PowerBASIC. It's letting me learn new things, which it the most fun of all.

I code my own web pages manually and using PowerBASIC is not unlike that. There are plenty of higher level tools to create pages, but the hands-on is much more fun -and provides more control over the results. That's kind of like how PowerBASIC advertises itself, isn't it!

Today, Petzold is on order, and you're right, it's about time.

But I haven't had a lack of materials/books to read. I have 3 books on Windows programming that I've been reading some. So while Petzold was on my list I just had not gotten around to ordering it. The trick will be to carve out the time to read it front-to-back (yes, I'll also skim to the parts I have questions about).

Thanks for "watching". It's what I like about this forum. And no, I'm not an exhibitionist.

[Cliff Nichols]

Let me know if its the same "Heres a puzzle...how would you solve it???" trait.

I once bought a book that I believe was Petzold, and it was so worthless that it was nothing more than "Hello World" with a couple of basic steps beyond that.

If I am wrong, then forgive me, for I got prejudice against a concept than many SWORE by, when it was worthless to me.

If I am wrong...please correct me so I may see the light of knowledge in an area that I refuse to look when others keep pressing that I look

[colin glenn]

The Petzold book I have weighs in at several pounds and is over 1,400 pages worth of worthwhile material to study.
http://www.charlespetzold.com/pw5/index.html

[Fred Harris]

The idea that I have to go outside PB documentation to learn to be good at PB is mind-boggling to someone used to Microsoft languages and their ton of documentation.

If its any consolation, Petzold's book is a Microsoft Press book, and many of the original architects of Windows served Petzold as technical advisers in his writting of it.