PostMessage to VB.NET messageloop

  • Thread starter Thread starter SM
  • Start date Start date
S

SM

Hello group,
i'm converting a VB6 application for .NET Framework.
The application depends on a DLL written in standard C.

The C DLL code creates an invisible window with CreateWindow()
with the WndProc function located into the VB.NET code.

Until the code was VB6/C code, they was OK.

Now the VB WndProc receives the startup message correctly
(WM_NCCREATE - WM_CREATE - WM_SIZE - .....)
but when i send (from the C code) custom messages (or
whatever kind of message) with PostMessage(....), using
as handle the same one returned from CreateWindow(..),
the WndProc doesn't receive them ....
I see this messages with Spy++ and all the parameters are OK.

What's the problem ?
Can i still use PostMessage() from C code to send a message
to .NET WndProc function ? I need to leave untouched the DLL ..

Thanks
 
Hi Stefano,

I probably can't get you. Let's try to broke it all down into smaller
pieces.

1. A C DLL that creates an invisible window and contains a message loop for
that window,
2. A VB .NET WinForms application that can receive WM_xxx messages from the
invisible window.
3. The VB .NET app's main window handle is somehow passed to the DLL.

The problem is that you can't get the right window handle for the VB .NET's
application main window?
Well, Form.Handle should be the property returing the right handle value
(you might need to call its ToInt32() method depending on how you have
declared the DLL's functions in VB .NET).
 
Hi Dmitriy,
i try to explain better, i know it is a little complex.. :-)

1. VB .NET application makes a call to C DLL function. One of the function
parameters is a pointer to a VB.NET function.
2. In this C DLL function, the code creates an invisible window with
CreateWindow() using for the message loop the function pointer passed.
3. C DLL saves the window handle in a DLL global variable for future uses
4. C DLL function sends a PostMessage( saved_handle, WM_custom, xx, yy) but this
message is never received from VB.NET function (the message is visible with
Spy++)
5. Even if C DLL sends a message (custom or standard) just after the
CreateWindow(..), VB.NET function never receive it.
6. VB.NET message loop receives startup standard messages as WM_CREATE, WM_SIZE,
WM_MOVE,
.....

Thanks
 
Stefano,
2. In this C DLL function, the code creates an invisible window with
CreateWindow() using for the message loop the function pointer passed.
3. C DLL saves the window handle in a DLL global variable for future uses
4. C DLL function sends a PostMessage( saved_handle, WM_custom, xx, yy) but this
message is never received from VB.NET function (the message is visible with
Spy++)
Click to expand...

It is not clear why should the VB .NET callback receive the message in the
first place? Is this VB .NET function actually a window procedure? If yes, I
would advice to pay maximum attention on HOW do you pass the function
pointer to the C DLL. Ensure you specify the right calling convention
(WINAPI that is), and that all parameters will be marshalled properly.

Then, it's not clear what is meant under "the message is never received". If
you would post some standard message, would it be received by the VB .NET
procedure? Does it gets called at all?

I am just trying to focus on the root of the problem, so please be patient
to tons of my questions :-)
 
Dmitriy,
thanks again for your attention,
It is not clear why should the VB .NET callback receive the message in the
first place? Is this VB .NET function actually a window procedure? If yes, I
would advice to pay maximum attention on HOW do you pass the function
pointer to the C DLL. Ensure you specify the right calling convention
(WINAPI that is), and that all parameters will be marshalled properly.
Click to expand...

Yes, it is a window procedure for the window created into the C DLL.
OK, i'll re-check all the parameters .... but i think if the address was wrong,
i should have a crash !!
Then, it's not clear what is meant under "the message is never received". If
you would post some standard message, would it be received by the VB .NET
procedure? Does it gets called at all?
Click to expand...

The VB.NET window procedure receives all the standard messages fired
(internally) from the CreateWindow() call.
When i explicitly want to post a message (custom or not) to the invisible window
from my DLL code,
i think the message will be sent to its window procedure but the .NET window
procedure is not fired !
I am just trying to focus on the root of the problem, so please be patient
to tons of my questions :-)
Click to expand...

Oh, don't worry !!! I understand that is not a clear architecture but
i'm migrating from an existent situation (VB6+C DLL), this
situation was created from previous programmer and I'm trying
to leave untouched the just-tested DLL. Maybe in the future I'll
have time to re-write also the DLL.....

Thanks a lot !
 
The VB.NET window procedure receives all the standard messages fired
(internally) from the CreateWindow() call.
When i explicitly want to post a message (custom or not) to the invisible window
from my DLL code,
i think the message will be sent to its window procedure but the .NET window
procedure is not fired !
Click to expand...

A-ha, now it's much more clear. So my suggestions are:

1. Check the custom message is registered (I believe there's an API function
to do that). Not sure the receiving party should also register the custom
message though.

2. The PostMessage function has some difficulties with marshalling custom
messages. Not sure what they meant in MSDN but here's the quote:

=== Cut ===
The system only does marshalling for system messages (those in the range 0
to WM_USER). To send other messages (those above WM_USER) to another
process, you must do custom marshalling.
=== Cut ===

I'd also suggest asking the more detailed question in the
dotnet.framework.interop newsgroup as it seems to be not related to the VB
..NET lanugage itself.
 
How are you declaring the delegate that is being passed in to the dll for
the Window procedure? If you are not keeping a reference to the delegate it
will be garbage collected.
 
Back
Top