Overridden WndProc not working in some cases?

C

Chris Ashley

I have an empty, invisible form which is just used for receiving
windows messages from other applications. I have overridden the WndProc
like so:


[System.Security.Permissions.PermissionSet(System.Security.Permissions.SecurityAction.Demand,
Name = "FullTrust")]
protected override void WndProc(ref Message m)
{

switch (m.Msg)
{
case ImageFileMsg.MSG_IF_NEW_DATA:
{
ProcessNewDataMessage(m);
break;
}
case ImageFileMsg.MSG_SCREEN_STARTLOG:
{
ProcessNewScreenMessage(m);
break;
}
default:
{
base.WndProc(ref m);
break;
}
}

}

The two messages come from different DLLs, both written in non-MFC C++.
For some reason the first message (MSG_IF_NEW_DATA) hits my app okay,
but the second message (MSG_SCREEN_STARTLOG) doesn't. I can't even see
the second message appear in Spy++ when I attach it to my window... but
I know the C++ DLL it is coming from works okay because a small C++
test app received the messages okay with the exact same calls. Is there
any sort of compilation or configuration option which affects which
messages my form can see?
 
S

Stoitcho Goutsev \(100\)

Chris,

I don't think there are any options. If the message is sent to correct HWND
it should hit the WndProc.
However the .NET application can filterout messages before they are
dispatched to the target window (Application.AddMessageFilter). It is also
possible that the numeric constant for the message is the same as some
constant that .NETinternaly uses, so it gets wrongfully processed by the
framework. If it is possible try to change the constant for this message.
The correct way of doing it is to use RegisterWindowMessage API.
 
C

Chris Ashley

Hi Stoitcho,

Thanks for your response.

I've now identified the problem. In the first and working case the
process of the message being sent was:

C# Win App -> C# DLL (Separate thread) -> Managed C++ Wrapper ->
Unmanaged C++ DLL

The second case where the messages weren't working was:

C# Win App -> C# DLL (Separate thread) -> Managed C++ Wrapper ->
Unmanaged C++ DLL -> Subsequent Unmanaged C++ DLL (in another separate
thread)

If I pass the window handle of my C# Win App (without launching a
separate thread) it seems to work fine and receives all messages.
However if I do what I was doing before which is creating a window in
my C# DLL which was in a separate thread, it doesn't work in the second
case.

I'm not sure if this is .NET behaviour or standard windows behaviour,
but at least I've found a solution (even if it isn't ideal).

Thanks,

Chris
Chris,

I don't think there are any options. If the message is sent to correct HWND
it should hit the WndProc.
However the .NET application can filterout messages before they are
dispatched to the target window (Application.AddMessageFilter). It is also
possible that the numeric constant for the message is the same as some
constant that .NETinternaly uses, so it gets wrongfully processed by the
framework. If it is possible try to change the constant for this message.
The correct way of doing it is to use RegisterWindowMessage API.


--
HTH
Stoitcho Goutsev (100)


Chris Ashley said:
I have an empty, invisible form which is just used for receiving
windows messages from other applications. I have overridden the WndProc
like so:


[System.Security.Permissions.PermissionSet(System.Security.Permissions.SecurityAction.Demand,
Name = "FullTrust")]
protected override void WndProc(ref Message m)
{

switch (m.Msg)
{
case ImageFileMsg.MSG_IF_NEW_DATA:
{
ProcessNewDataMessage(m);
break;
}
case ImageFileMsg.MSG_SCREEN_STARTLOG:
{
ProcessNewScreenMessage(m);
break;
}
default:
{
base.WndProc(ref m);
break;
}
}

}

The two messages come from different DLLs, both written in non-MFC C++.
For some reason the first message (MSG_IF_NEW_DATA) hits my app okay,
but the second message (MSG_SCREEN_STARTLOG) doesn't. I can't even see
the second message appear in Spy++ when I attach it to my window... but
I know the C++ DLL it is coming from works okay because a small C++
test app received the messages okay with the exact same calls. Is there
any sort of compilation or configuration option which affects which
messages my form can see?
Click to expand...
Click to expand...
 
S

Stoitcho Goutsev \(100\)

Chris,

I'm sorry, but I'm completely lost. I couldn't follow your cases. Is there
any way to simplify the explanation or elaborate a bit on these two cases?


--
Stoitcho Goutsev (100)

Chris Ashley said:
Hi Stoitcho,

Thanks for your response.

I've now identified the problem. In the first and working case the
process of the message being sent was:

C# Win App -> C# DLL (Separate thread) -> Managed C++ Wrapper ->
Unmanaged C++ DLL

The second case where the messages weren't working was:

C# Win App -> C# DLL (Separate thread) -> Managed C++ Wrapper ->
Unmanaged C++ DLL -> Subsequent Unmanaged C++ DLL (in another separate
thread)

If I pass the window handle of my C# Win App (without launching a
separate thread) it seems to work fine and receives all messages.
However if I do what I was doing before which is creating a window in
my C# DLL which was in a separate thread, it doesn't work in the second
case.

I'm not sure if this is .NET behaviour or standard windows behaviour,
but at least I've found a solution (even if it isn't ideal).

Thanks,

Chris
Chris,

I don't think there are any options. If the message is sent to correct
HWND
it should hit the WndProc.
However the .NET application can filterout messages before they are
dispatched to the target window (Application.AddMessageFilter). It is
also
possible that the numeric constant for the message is the same as some
constant that .NETinternaly uses, so it gets wrongfully processed by the
framework. If it is possible try to change the constant for this message.
The correct way of doing it is to use RegisterWindowMessage API.


--
HTH
Stoitcho Goutsev (100)


Chris Ashley said:
I have an empty, invisible form which is just used for receiving
windows messages from other applications. I have overridden the WndProc
like so:


[System.Security.Permissions.PermissionSet(System.Security.Permissions.SecurityAction.Demand,
Name = "FullTrust")]
protected override void WndProc(ref Message m)
{

switch (m.Msg)
{
case ImageFileMsg.MSG_IF_NEW_DATA:
{
ProcessNewDataMessage(m);
break;
}
case ImageFileMsg.MSG_SCREEN_STARTLOG:
{
ProcessNewScreenMessage(m);
break;
}
default:
{
base.WndProc(ref m);
break;
}
}

}

The two messages come from different DLLs, both written in non-MFC C++.
For some reason the first message (MSG_IF_NEW_DATA) hits my app okay,
but the second message (MSG_SCREEN_STARTLOG) doesn't. I can't even see
the second message appear in Spy++ when I attach it to my window... but
I know the C++ DLL it is coming from works okay because a small C++
test app received the messages okay with the exact same calls. Is there
any sort of compilation or configuration option which affects which
messages my form can see?
Click to expand...
Click to expand...
Click to expand...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Threading and WndProc - basic question 1
How to handle WM_GETTEXT in overridden WndProc ? 2
Threading and WndProc - basic question 2
WndProc not working as expected? 4
trouble using delegate in WndProc 2
Detecting a USB drive arrival/removal, where the drive has beenunmounted (drive letter removed) 0
is there a faq about the square bracket thingies in c# 4
Can't properly handle NM_CUSTOMDRAW in listview 4

Top