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?
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?
Comment