| Groups | Blog | Home |
dotnet sdk : PostMessage to VB.NET messageloop
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. [quoted text, click to view] "SM" <stefano_mora@hotmail.com> wrote in message news:u1D$QP0rDHA.3416@tk2msftngp13.phx.gbl... > 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 > -- > Stefano M > email: *@* > (remove *) > > >
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 -- Stefano M email: *@* (remove *)
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 M email: *@* (remove *)
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). -- Dmitriy Lapshin [C# / .NET MVP] X-Unity Test Studio http://x-unity.miik.com.ua/teststudio.aspx Bring the power of unit testing to VS .NET IDE [quoted text, click to view] "SM" <stefano_mora@hotmail.com> wrote in message
news:u1D$QP0rDHA.3416@tk2msftngp13.phx.gbl... > 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 > -- > Stefano M > email: *@* > (remove *) > > >
Dmitriy,
thanks again for your attention, [quoted text, click to view] > 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. 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 !! [quoted text, click to view] > 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? 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 ! [quoted text, click to view] > I am just trying to focus on the root of the problem, so please be patient > to tons of my questions :-) 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 ! -- Stefano M email: *@* (remove *)
Stefano,
[quoted text, click to view] > 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++) 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 Lapshin [C# / .NET MVP] X-Unity Test Studio http://x-unity.miik.com.ua/teststudio.aspx Bring the power of unit testing to VS .NET IDE [quoted text, click to view] "Ste M" <stefano_mora@hotmail.com> wrote in message
news:bpi4bk$fdq$1@fata.cs.interbusiness.it... > 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 M > email: *@* > (remove *) > > >
[quoted text, click to view]
> 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 ! 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. -- Dmitriy Lapshin [C# / .NET MVP] X-Unity Test Studio http://x-unity.miik.com.ua/teststudio.aspx Bring the power of unit testing to VS .NET IDE [quoted text, click to view] "SM" <stefano_mora@hotmail.com> wrote in message
news:ue7IMH2rDHA.2340@TK2MSFTNGP12.phx.gbl... > 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. > > 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? > > 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 :-) > > 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 ! > -- > Stefano M > email: *@* > (remove *) > > >
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |