Overridden WndProc not working in some cases?

  • Thread starter Thread starter Chris Ashley
  • Start date Start date
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?
 
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.
 
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...
 
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...
 
Back
Top