Re: Custom Control - Notifcation Messages

Tech-Archive recommends: Speed Up your PC by fixing your registry

Hi Dan,

I am not that good with WM_PAINT and those other messages listed in the link, so lets remove WM_PAINT message
from the conversation. It is irrelevant.
The link did provide me with something I was looiking for WM_ERASEBKGND.
Normally, you just return TRUE to eliminate flicker, but I am finding I need to Invalidate the Background.
So I can use that. Thanks.
http://msdn2.microsoft.com/en-us/library/ms648055.aspx

From TN061:
'The function CWnd::OnNotify handles notification messages. Its default
implementation checks the message map for notification handlers to call.
In general, you do not override OnNotify. Instead, you provide a handler
function and add a message-map entry for that handler to the message map
of your owner window's class.'
The tech note might say that, but that is not how it works.
But, go ahead and look for WM_NOTIFY in the messages window. It is not there.
It is in the over-ride window. Then, when you click on the override, it is an override. Imagine that.
It is not not a message.
I haven't tried to change it to a message map entry. Perhaps it would work? It sounds like it should.

There may be philosophies to programing, but, beliefs?
Philosophy Shmilosophy. It's the talk on the cereral box. (Name that tune.)
I believe that is what is happening and I do believe I am correct.

WM_NOTIFY is sent by controls, not the system. That is the difference.
They are just messages, just like any other message.
Sure, the system sends the message, but I can also use it like I was using it.
It may not be standard practice, but it is possible to use it.
I bet at one time with old MFC, they used to send messages using WM_PARENTNOTIFY.
Then, at some point, they realized they needed to seperate the two, so they added WM_NOTIFY.
God knows that is what I do to my code on a daily basis.
(Note that the message is identical in most respects to WM_PARENTNOTIFY)
I mean, that is what I was originally thinking. Notify the parent. Parent notify. It makes sense.
I just didn't realize that WM_NOTIFY was control specific.
WM_NOTIFYPARENT_CONTROL sounds like a better message, but that is not to be.

I see no gain in reinventing perfectly good controls. Especially if the
objective is to eliminate 'extra processing'.
It all depends on what the control is supposed to do.
They added WM_EX_NOPARENTNOTIFY for a purpose.
That purpose is 2 fold.
First, it eliminates extra processing
Second, it eliminates extra messages being sent.
Why, perhaps, do you think they added that Style?
You may not come across the need to add that style,
but somebody needed it at one time, so they added it.
I addded the style in my app to one of my controls.
For the simple fact that it is a fast update control and I need to eliminate messages from clogging up the system.
I dont care when it is created or destroyed and I don't need any mouse messages.

Oh, P.S.
I did change it from WM_PARENTNOTIFT to WM_NOTIFY
I also changed the nmhdr.code to WM_LBUTTONUP, WM_LBUTTONDOWN, WM_MOUSEMOVE and another registered messages I am using.
It is working nicely and within conforming standard practice.

Thanks,
"Dan Bloomquist" <public21@xxxxxxxxxxx> wrote in message news:vk0ui.13592$B25.11715@xxxxxxxxxxxxxxxx
Nobody wrote:

Hi Dan,

There is nothing in this link that says anything about WM_PAINT.
That is a totally seperatate message
http://msdn2.microsoft.com:80/en-us/library/ms632638.aspx

quote: 'the system sends the message...'
You are not 'the system'.

http://msdn2.microsoft.com/en-us/library/ms534901.aspx
quote: 'The WM_PAINT message is generated by the system and should not
be sent by an application.'

It is my belief...

There may be philosophies to programing, but, beliefs?

The point of common controls is so you don't have to re-invent wheels.
It is one thing to extend their functionality but another to break what
is already there.

(WM_PARENNOTIFY shows up in the messages window.

So does WM_PAINT. And those messages are to be 'handled', not generated
by the programer.

WM_NOTIFY does not show up. It is an override.)

From TN061:
'The function CWnd::OnNotify handles notification messages. Its default
implementation checks the message map for notification handlers to call.
In general, you do not override OnNotify. Instead, you provide a handler
function and add a message-map entry for that handler to the message map
of your owner window's class.'

And:

'Common controls are child windows that send notification messages to
the parent window when events....'

WM_NOTIFY is sent by controls, not the system. That is the difference.

I didn't really know about WM_NOTIFY and thought I could just as well use WM_PARENTNOTIFY,
but, after further investigation, controls use WM_NOTIFY instead, so that is really what I should be using.

Why would you want to do that?

The question followed your post at:
'( I wonder if it can be shut off as well?) '


WS_EX_NOPARENTNOTIFY
Because it is extra code processing that is not necessary.
Why would a control need to constantly send parent notifications if the parent doesn't need them.
I actually think it should be the default setting.
So, in my code, I send my own mouse messages with WM_NOTIFY and I could turn off the standard
messages since they are not needed.
It probably works quick enough that it doesn't matter.
But, it is just something to keep in mind.


Best, Dan.

.

Quantcast