problems with setparent in vb .net 2008
-
Hi, I posted this in general questions and then realized I should have posted it here. I have a large vb6 app that I turned into a dll so I could run it from vb .net. When I run the vb6 & .net projects in debug everything works fine. If I open the forms non modally everything works fine all the time. However when I compile the vb6 into a dll the vb6 forms are not being placed in the .Net container form when I open them modally (non modal is OK). The vb6 form just sits in the upper left of the screen. I came up with this solution based on an article by Eduardo Campano on embedding vb6 forms in .Net applications from July 2007. Great article and a good idea if you have a million lines of code to convert to .net. I have sample code but don't see how to upload it to the forum. The code for loading the vb6 into the container is from the container load event in .net: SetParent(mintFormHandle, Me.Handle.ToInt32) SendMessage(Me.Handle.ToInt32, WM_NCACTIVATE, 1, 0) SetForegroundWindow(Me.Handle.ToInt32) LockWindowUpdate(0)
Such a Larry
-
Hi, I posted this in general questions and then realized I should have posted it here. I have a large vb6 app that I turned into a dll so I could run it from vb .net. When I run the vb6 & .net projects in debug everything works fine. If I open the forms non modally everything works fine all the time. However when I compile the vb6 into a dll the vb6 forms are not being placed in the .Net container form when I open them modally (non modal is OK). The vb6 form just sits in the upper left of the screen. I came up with this solution based on an article by Eduardo Campano on embedding vb6 forms in .Net applications from July 2007. Great article and a good idea if you have a million lines of code to convert to .net. I have sample code but don't see how to upload it to the forum. The code for loading the vb6 into the container is from the container load event in .net: SetParent(mintFormHandle, Me.Handle.ToInt32) SendMessage(Me.Handle.ToInt32, WM_NCACTIVATE, 1, 0) SetForegroundWindow(Me.Handle.ToInt32) LockWindowUpdate(0)
Such a Larry
larry118 wrote:
Great article and a good idea if you have a million lines of code to convert to .net.
Calling VB6 code from VB.NET is not a conversion. It's merely building another layer on something that should have been retired a few years ago. What does "sit there" mean? Does it still process messages? You can test if it is by dragging another application over it - if a white smear appears, then the paint handler is no longer being called. I suggest you turn your DLL back into an executable; that's the easiest way. Outside of that, the recommended way to use legacy code would be by using the InterOp Form Toolkit[^].
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
larry118 wrote:
Great article and a good idea if you have a million lines of code to convert to .net.
Calling VB6 code from VB.NET is not a conversion. It's merely building another layer on something that should have been retired a few years ago. What does "sit there" mean? Does it still process messages? You can test if it is by dragging another application over it - if a white smear appears, then the paint handler is no longer being called. I suggest you turn your DLL back into an executable; that's the easiest way. Outside of that, the recommended way to use legacy code would be by using the InterOp Form Toolkit[^].
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Yes of course the best thing would be to convert the code but its not going to happen right away when there is so much code and so many customers and users (100's). By stripping the vb6 forms borders and putting them in a .net wrapper we get a really nice look in Windows 7 & 8 and now we have more time to properly analyze and convert the remaining code and marketing can demo an upgraded look and feel to the application. As far as sit there. The vb6 form is frozen but you can drag stuff over it without a paint problem. I wish I could upload the code. Larry
Such a Larry
-
Yes of course the best thing would be to convert the code but its not going to happen right away when there is so much code and so many customers and users (100's). By stripping the vb6 forms borders and putting them in a .net wrapper we get a really nice look in Windows 7 & 8 and now we have more time to properly analyze and convert the remaining code and marketing can demo an upgraded look and feel to the application. As far as sit there. The vb6 form is frozen but you can drag stuff over it without a paint problem. I wish I could upload the code. Larry
Such a Larry
larry118 wrote:
I wish I could upload the code.
VB6 has been dead to me for a few years.
larry118 wrote:
and now we have more time to properly analyze and convert the remaining code and marketing can demo an upgraded look and feel to the application
Microsoft extended support ended in 1998. Your excuse was valid until 2007.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
Yes of course the best thing would be to convert the code but its not going to happen right away when there is so much code and so many customers and users (100's). By stripping the vb6 forms borders and putting them in a .net wrapper we get a really nice look in Windows 7 & 8 and now we have more time to properly analyze and convert the remaining code and marketing can demo an upgraded look and feel to the application. As far as sit there. The vb6 form is frozen but you can drag stuff over it without a paint problem. I wish I could upload the code. Larry
Such a Larry
Larry you have my sincere sympathies, imagine working for an organisation so forward thinking that they don't plan for an end of life on their development platform. Then wait 6 YEARS after the end of support to attempt to remedy the situation. To top it off the development is now being driven by the marketing departments need to show of a new look and feel. You really should submit your situation to WTF it sounds like a classic to me!
Never underestimate the power of human stupidity RAH
-
Larry you have my sincere sympathies, imagine working for an organisation so forward thinking that they don't plan for an end of life on their development platform. Then wait 6 YEARS after the end of support to attempt to remedy the situation. To top it off the development is now being driven by the marketing departments need to show of a new look and feel. You really should submit your situation to WTF it sounds like a classic to me!
Never underestimate the power of human stupidity RAH
These are really good people. I like them and don't mind being responsible for converting the code. I have made some progress on this issue. The setparent now seems to be working. The vb6 form is now appearing in the .net container. The problem was passing the parent from vb6 and that is now handled. So setparent works now but it's followed by a send message, setforegroundwindow and lockwindowupdate which appear not to be working. My declarations are as follows: _ Private Shared Function SetParent(ByVal hWndChild As IntPtr, ByVal hWndNewParent As IntPtr) As Int32 End Function Public Declare Auto Function SendMessage Lib "user32.dll" ( _ ByVal hWnd As IntPtr, _ ByVal wMsg As Int32, _ ByVal wParam As Int32, _ ByVal s As String _ ) As Int32 _ Private Shared Function SetForegroundWindow(ByVal hwnd As IntPtr) As IntPtr End Function _ Private Shared Function LockWindowUpdate(ByVal hwndLock As IntPtr) As Boolean End Function and the code is: SetParent(mintFormHandle, Me.Handle.ToInt32) SendMessage(mintFormHandle, WM_ACTIVATE, 1, IntPtr.Zero) SetForegroundWindow(mintFormHandle) LockWindowUpdate(0) Me.Refresh() Any suggestions?
Such a Larry
-
These are really good people. I like them and don't mind being responsible for converting the code. I have made some progress on this issue. The setparent now seems to be working. The vb6 form is now appearing in the .net container. The problem was passing the parent from vb6 and that is now handled. So setparent works now but it's followed by a send message, setforegroundwindow and lockwindowupdate which appear not to be working. My declarations are as follows: _ Private Shared Function SetParent(ByVal hWndChild As IntPtr, ByVal hWndNewParent As IntPtr) As Int32 End Function Public Declare Auto Function SendMessage Lib "user32.dll" ( _ ByVal hWnd As IntPtr, _ ByVal wMsg As Int32, _ ByVal wParam As Int32, _ ByVal s As String _ ) As Int32 _ Private Shared Function SetForegroundWindow(ByVal hwnd As IntPtr) As IntPtr End Function _ Private Shared Function LockWindowUpdate(ByVal hwndLock As IntPtr) As Boolean End Function and the code is: SetParent(mintFormHandle, Me.Handle.ToInt32) SendMessage(mintFormHandle, WM_ACTIVATE, 1, IntPtr.Zero) SetForegroundWindow(mintFormHandle) LockWindowUpdate(0) Me.Refresh() Any suggestions?
Such a Larry
larry118 wrote:
Any suggestions?
Both the SetForgroundWindow and the LockWindowUpdate should be superfluous. The parent would already be the foreground-window and thus active. Painting the window should not have been locked in the first place. If it is, then you'll probably need to send a WM_SETREDRAW to reactivate.
larry118 wrote:
These are really good people.
Them being kind does not make VB6 any less dead. Companies that keep building on outdated blocks tend to become outdated themselves.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
larry118 wrote:
Any suggestions?
Both the SetForgroundWindow and the LockWindowUpdate should be superfluous. The parent would already be the foreground-window and thus active. Painting the window should not have been locked in the first place. If it is, then you'll probably need to send a WM_SETREDRAW to reactivate.
larry118 wrote:
These are really good people.
Them being kind does not make VB6 any less dead. Companies that keep building on outdated blocks tend to become outdated themselves.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
Thanks but that did not help the vb6 form is still frozen. As soon as I get this working I can begin the conversion.
Such a Larry
larry118 wrote:
Thanks but that did not help the vb6 form is still frozen.
The difference between an executable and a dll is an executing thread. The easy way is to turn it into an executable, the correct way is to google for the Interop Toolkit.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
larry118 wrote:
Thanks but that did not help the vb6 form is still frozen.
The difference between an executable and a dll is an executing thread. The easy way is to turn it into an executable, the correct way is to google for the Interop Toolkit.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Sadly there is very little documentation on the interop toolkit the way I am using it. Ironically the answer was in the order of doing things. If I execute the setparent function before I open the vb .net form it works perfectly. Lots of time lost for a stupid problem.
Such a Larry