problem with unmanaged pointers
-
Hello, I have an MFC application that i would like to mix with Managed C++. I changed the compiler settings and everything compiles fine. For the moment I did not write any managed code but I have the message as follows at execution: "An unhandled exception of type 'System.TypeLoadException' occurred in ApplicationName.exe Additional information: Could not load type _TREEITEM from assembly ApplicationName, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null." This message occurs before execution of the function that returns a pointer. I have put a breakpoint in it but it is never called. I think it is unmanaged pointer problem because I have modified the function to return a reference to CWnd and everything was Ok. below is the code snipped, Could please help me because I am 100% newbee with C++/CLI:confused: Declaration
// Attributes
private:
CWnd* m_pView;//Declaration of the function
CWnd* CreateTreeView();Definition
//Constructor definition
BnBPaneView::BnBPaneView():m_pView(NULL){}//definition of the function
int BnBPaneView::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
if (CWnd::OnCreate(lpCreateStruct) == -1)
return -1;m\_pView = CreateTreeView();// error message here. The function is not called at all.//Create view is a function that creates a treeview and uses a CTreeCtrl object.
etc..
.
.
.
} -
Hello, I have an MFC application that i would like to mix with Managed C++. I changed the compiler settings and everything compiles fine. For the moment I did not write any managed code but I have the message as follows at execution: "An unhandled exception of type 'System.TypeLoadException' occurred in ApplicationName.exe Additional information: Could not load type _TREEITEM from assembly ApplicationName, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null." This message occurs before execution of the function that returns a pointer. I have put a breakpoint in it but it is never called. I think it is unmanaged pointer problem because I have modified the function to return a reference to CWnd and everything was Ok. below is the code snipped, Could please help me because I am 100% newbee with C++/CLI:confused: Declaration
// Attributes
private:
CWnd* m_pView;//Declaration of the function
CWnd* CreateTreeView();Definition
//Constructor definition
BnBPaneView::BnBPaneView():m_pView(NULL){}//definition of the function
int BnBPaneView::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
if (CWnd::OnCreate(lpCreateStruct) == -1)
return -1;m\_pView = CreateTreeView();// error message here. The function is not called at all.//Create view is a function that creates a treeview and uses a CTreeCtrl object.
etc..
.
.
.
}i don't see anything involving managed code at all here so I'm not sure how the problem could be with unmanaged pointers. BnBPaneView is an unmanaged class, right (derived from an MFCclass)? Mark
"Go that way, really fast. If something gets in your way, turn."
-
i don't see anything involving managed code at all here so I'm not sure how the problem could be with unmanaged pointers. BnBPaneView is an unmanaged class, right (derived from an MFCclass)? Mark
"Go that way, really fast. If something gets in your way, turn."
Yes it is unmanaged, derived from CWnd: class BnBPaneView : public CWnd Actually all what I have done is to change the compiler settings recommended in the MSDN: Use managed extensions = yes Enable minimum Rebuild = no basic runtime checks = default And before changing those settings, the application was working fine.
-
Yes it is unmanaged, derived from CWnd: class BnBPaneView : public CWnd Actually all what I have done is to change the compiler settings recommended in the MSDN: Use managed extensions = yes Enable minimum Rebuild = no basic runtime checks = default And before changing those settings, the application was working fine.
hmm OK. I sure forgot about this - I personally used #pragma managed/unmanaged to compile all my MFC code to native early on (when I first switched to mixed-mode) otherwise I'd see this all the time :) Here's a few links, all with the same fix... TypeLoadException in code using common controls[^] BUG: HTREEITEM May Cause TypeLoadException in a Managed C++ Application[^] Could not loa type _TREEITEM[^]
"Go that way, really fast. If something gets in your way, turn."
-
hmm OK. I sure forgot about this - I personally used #pragma managed/unmanaged to compile all my MFC code to native early on (when I first switched to mixed-mode) otherwise I'd see this all the time :) Here's a few links, all with the same fix... TypeLoadException in code using common controls[^] BUG: HTREEITEM May Cause TypeLoadException in a Managed C++ Application[^] Could not loa type _TREEITEM[^]
"Go that way, really fast. If something gets in your way, turn."
Does that mean that those who want to mix their applications must specify #pragma unmanaged before all their functions that are implemented with native code? It is a hudge work to pass through thousands of functions. While reading some articles on the subject, I understood that thanks to JIW ( just it works), there is nothing to do except changing the compiler settings. And regarding MFC applications, following directives #using #using using namespace System; using namespace System::Windows::Forms; are to be added in the stdafx.h file.
-
Does that mean that those who want to mix their applications must specify #pragma unmanaged before all their functions that are implemented with native code? It is a hudge work to pass through thousands of functions. While reading some articles on the subject, I understood that thanks to JIW ( just it works), there is nothing to do except changing the compiler settings. And regarding MFC applications, following directives #using #using using namespace System; using namespace System::Windows::Forms; are to be added in the stdafx.h file.
Arris7 wrote:
While reading some articles on the subject, I understood that thanks to JIW ( just it works), there is nothing to do except changing the compiler settings.
That's correct.
Arris7 wrote:
Does that mean that those who want to mix their applications must specify #pragma unmanaged before all their functions that are implemented with native code?
No. You can, but it's not necessary. If you decide to use #pragma unmanaged/unmanaged, they effect code from that point on, until another is encountered, or the end of file is reached. That means they only need to be at the top of a source file (under the #includes), not around every function. This worked well for me going from a large MFC code base to adding managed code. That also means you can mix native/CLR compilation in the same source file.
Arris7 wrote:
And regarding MFC applications, following directives #using #using using namespace System; using namespace System::Windows::Forms; are to be added in the stdafx.h file.
I suppose you could put those in the precompiled header. I'm not sure what most people do. I personally include just the ones I need on a per-.cpp/.h file basis, especially with namespaces. Did the TreeView struct stuff work out ok? Mark
"Go that way, really fast. If something gets in your way, turn."
-
Arris7 wrote:
While reading some articles on the subject, I understood that thanks to JIW ( just it works), there is nothing to do except changing the compiler settings.
That's correct.
Arris7 wrote:
Does that mean that those who want to mix their applications must specify #pragma unmanaged before all their functions that are implemented with native code?
No. You can, but it's not necessary. If you decide to use #pragma unmanaged/unmanaged, they effect code from that point on, until another is encountered, or the end of file is reached. That means they only need to be at the top of a source file (under the #includes), not around every function. This worked well for me going from a large MFC code base to adding managed code. That also means you can mix native/CLR compilation in the same source file.
Arris7 wrote:
And regarding MFC applications, following directives #using #using using namespace System; using namespace System::Windows::Forms; are to be added in the stdafx.h file.
I suppose you could put those in the precompiled header. I'm not sure what most people do. I personally include just the ones I need on a per-.cpp/.h file basis, especially with namespaces. Did the TreeView struct stuff work out ok? Mark
"Go that way, really fast. If something gets in your way, turn."
Mark, Thank you so much for those great details, I have added #pragma unmanaged on the top of all my classes under #include. Now it compiles and execute very fine. I just noticed that compilation and buid process has slow down. This time I agree it is JIW;)
-
Mark, Thank you so much for those great details, I have added #pragma unmanaged on the top of all my classes under #include. Now it compiles and execute very fine. I just noticed that compilation and buid process has slow down. This time I agree it is JIW;)
You're welcome! I hope I could help. The only real slowdown I've noticed is when starting mixed-mode apps in the debugger :) Cheers! Mark
"Go that way, really fast. If something gets in your way, turn."