Windows message sent to control

  • Thread starter Thread starter Edward Diener
  • Start date Start date
E

Edward Diener

If a Windows message is sent directly to control, does the framework
automatically pick up the message and generate the appropriate property
change, method call, or event from it ?

The reason I ask is that I am creating a control derived from one of the
framework controls and I need to know whether I need to handle certain
windows messages to the control which my derived control is interested in.
If the framework picks up the message and generates the appropriate property
change, method call, or event, then my code can override the latter. If not,
then I need to handle the message in my own WndProc.
 
If a Windows message is sent directly to control, does the framework
automatically pick up the message and generate the appropriate property
change, method call, or event from it ?

The reason I ask is that I am creating a control derived from one of the
framework controls and I need to know whether I need to handle certain
windows messages to the control which my derived control is interested in.
If the framework picks up the message and generates the appropriate
property
change, method call, or event, then my code can override the latter. If
not,
then I need to handle the message in my own WndProc.
Click to expand...

do you mean any specific message?

in general, winform events operate rather on winform level.

for example, if you send WM_SETTEXT to a textbox control, you do not get
TextChanged event since it is raised only when the Text property is changed
(however, if the TextChanged event responded to EN_UPDATE message, it would
react to WM_SETTEXT).

Wiktor Zychla
 
Wiktor said:
do you mean any specific message?
Click to expand...

Yes. I am interested, in general, whether .net picks up Windows messages
sent to a component, and changes the corresponding property appropriately,
causes an appropriate method to occur, or triggers an appropriate event. I
am a component developer, developing a component derived from a base class
component.
in general, winform events operate rather on winform level.

for example, if you send WM_SETTEXT to a textbox control, you do not
get TextChanged event since it is raised only when the Text property
is changed (however, if the TextChanged event responded to EN_UPDATE
message, it would react to WM_SETTEXT).
Click to expand...

You are saying that sending WM_SETTEXT to a control does not change the Text
property ? That is essentially what I am asking. Do Windows messages sent to
a .net control cause the appropriate property to change ?

A practical example. I have a derived control in which I only allow the text
to be changed under certain conditions. I am overriding set_Text, the Text
property's setter, for a particular derived control I am writing, calling
the base class's set_Text only if I decide that the change should be
allowed. If an end-user sends a WM_SETTEXT message directly to the control,
does the base class control call my overridden method before making the
change ? If it does not, then I must also handle the WM_SETTEXT message at
the WinProc level. If it does, then I only need to handle set_Text as an
overridden property setter.

The practical example is the gist of my question. While I can duplicate
logic at both the property/method/event level and at the Win32 message level
of my component, it would be easier to stick to the former if the way .net
works is always to translate directly the Win32 message to a .net
property/method/event before the change is made. That way, if I do not want
some change to be made, based on the criteria of my component, I simply do
not call down to my base class to complete the change.
 
You can change the way WM_SETTEXT is handled via the ControlStyles.CacheText
control style. The default behavior is that the text is cached, which
removes lots of unnecessary managed/unmanaged marshalling overhead. By
calling SetStyle(ControlStyles.CacheText, true) you will persuade it to use
WM_SETTEXT / WM_GETTEXT everytime you set/get the property value, though I'm
not sure whether it will also cause the TextChanged event to be invoked when
the text is changed from an external source.

You might want to override the WndProc method if it doesn't work
automatically:

const int WM_SETTEXT = 0x000C;

protected override void WndProc(ref Message m)
{
base.WndProc(m); // first perform the default processing

if (m.Msg == WM_SETTEXT)
OnTextChanged(EventArgs.Empty);
}

HTH,
Stefan
 
©tefan ©imek said:
You can change the way WM_SETTEXT is handled via the
ControlStyles.CacheText control style. The default behavior is that
the text is cached, which removes lots of unnecessary
managed/unmanaged marshalling overhead. By calling
SetStyle(ControlStyles.CacheText, true) you will persuade it to use
WM_SETTEXT / WM_GETTEXT everytime you set/get the property value,
though I'm not sure whether it will also cause the TextChanged event
to be invoked when the text is changed from an external source.
Click to expand...

Thanks for the note. WM_SETTEXT is just one of many Windows messages which I
may want to handle for the same reason as explained in the opening post. It
looks like, in order to write a robust derived control, that one must handle
appropriate Windows messages at the WndProc level as well as override
properties, methods, and events.
You might want to override the WndProc method if it doesn't work
automatically:
Click to expand...

Yes, this is what I had planned in the first place. My general method in
every situation is simply to handle the Windows message, do what one wants
to do, and call the base class's WndProc method. Then one doesn't have to
worry about exactly what the base class does with a particular message. Of
course your code below works fine with just WM_SETTEXT but it requires
knowing whether the base class's handling of WM_SETTEXT calls OnTextChanged
or not. I do not want to worry what my base class does for any given Windows
message I handle in my derived class.
 
Back
Top