|
Hi Mark,
No that, Here is the list of modules that work and the list
that does not work.
works works DoesNot work
------------- ------------- -------------
Unmanaged App Unmanaged App Unmanaged App
| | |
UnMng2Mng Bridge Unmanaged Dll Unmanaged Dll
| |
Assembly DLL UnMng2Mng Bridge
|
Assembly DLL
Jose Viveiros
|
|
|
|
|
Hi Mark,
Let me try again (as my last email colapsed some spaces)
works:
Unmanaged App -> UnMng2Mng Bridge -> Assembly DLL
works:
Unmanaged App -> Unmanaged Dll
DoesNot works:
Unmanaged App -> Unmanaged Dll -> UnMng2Mng Bridge -> Assembly DLL
|
|
|
|
|
Ok got it, thanks. And what is failing and where? LoadLibrary on the bridge DLL?
|
|
|
|
|
LoadLibrary( ) is failing to load the Unmanaged DLL if that DLL links to the unManged2Manged Bridge.
What is strange is that the Brige loads fine if it is loaded directly from the Unmanaged app but it causes problem if you try to use it with a unmanged Dll in between ????
Jose Viveiros
|
|
|
|
|
Jose Viveiros wrote: ...if that DLL links to the unManged2Manged Bridge.
How is this "link" done? Through an import library or explicitly with LoadLibrary?
If LoadLibrary, then where are you calling that from in the unmanaged DLL?
|
|
|
|
|
hum !
The link between the unmanaged Dll & the Bridge is not done via loadLibrary.
I link in the Bridge.lib and include bridge.h. Is this a problem?
The link between the App & the unmanged Dll does use loadLibrary
Thanks Jose
Jose Viveiros
|
|
|
|
|
Jose Viveiros wrote: I link in the Bridge.lib and include bridge.h. Is this a problem?
Hmm no, it shouldn't be. Calling LoadLibrary from DllMain is a problem - that's why I asked.
1) works:
Unmanaged App -> UnMng2Mng Bridge -> Assembly DLL
2) works:
Unmanaged App -> Unmanaged Dll
3) DoesNot works:
Unmanaged App -> Unmanaged Dll -> UnMng2Mng Bridge -> Assembly DLL
So using method 1 above, you linked using Bridge.lib, correct? If that worked then I would
expect method 3 to work.
Are you doing anything with entry code in your DLLs (DllMain)??
I had problems once with mixed MFC and managed/unmanaged DLLs and found the following article to
be helpful. Although the topic of the article doesn't match the problem, the "Resolution" section
has great info on how to initialize the C runtime (CRT) if you're using it in your DLLs...
You receive linker warnings when you build Managed Extensions for C++ DLL projects[^]
This article has interesting info as well, although it probably doesn't apply to the problem you
are having: Mixed DLL Loading Problem[^]
|
|
|
|
|
Hi Mark,
Yes I was also expecting that if method 1 worked method 3 would too. I will check the two articles you send me and I'll let you know if they help me thanks for your help.
|
|
|
|
|
Greetings,
Let's say I do this:
vector<cmyclass *=""> m_vMyVector;
void SomeFunction(CString strID, bool bStatus)
{
CMyClass * pMyObj = new CMyClass(strID, bStatus);
m_vMyVector.push_back(pMyObj);
pMyObj = NULL;
}
Let's say SomeFunction(...) is in a loop and I create several of these objects. When I call m_vMyVector.clear() will there be a memory leak? In essence, I want to know if I have to go back and call delete on each of the elements in m_vMyVector or will the memory be freed once I call the vector's "clear" method or once the vector is destroyed when the class containing it is destroyed. Also, once I add pMyObj to the vector and reassign the one in the function to point to null, the vector still retains its own valid pointers to the objects in memory, correct?
Thanks for any help or insight you can provide.
Sincerely,
BP
|
|
|
|
|
You will need to loop the vector to delete each item individually, unless you are using auto_ptr thingies.
it = m_vMyVetor.begin();
while (it!= m_vMyVector.end() )
{
delete *it;
++it;
}
m_vMyVector.clear();
and you are correct about the second thing, IMO, assign it back to NULL is not necessary, but a nice touch.
|
|
|
|
|
Thanks,
I appreciate your response.
BP
|
|
|
|
|
Hi,
It's not safe to use auto_ptr in a standard container (reference: see e.g. here[^], here[^]
But generally, smart pointers is the way to go. (only auto_ptr is a troubled implementation)
I've written an article about the smart pointer library included with boost - Clickety[^]. That might give you some ideas.
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers! We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP Linkify!|Fold With Us!
|
|
|
|
|
Maximilien wrote: auto_pt
do me a favor, never use auto_ptr
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers! We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP Linkify!|Fold With Us!
|
|
|
|
|
Thanks PeterChen,
I have heard a lot of great things about boost. Being new to programming, it seems a bit intimidating to use and I am admittedly frightened at the prospect of including it then having to deal with Visual Studio 2003 not playing nice with it. Is boost easy to use?
At any rate, I'll check out your article.
Peace,
BP
|
|
|
|
|
boost can certainly be intimidating. It is a collection of many different libraries, and some of them are clearly made for advanced program(mer)s.
The smart pointers are an exception. They are (IMO) a very important concept, maybe the first step away from beginner towards advanced programming. They should be easy to understand if you have mastered basic memory management and RAII (using constructors and destructors to acquire and release resources like memory, file handles, ...). I also tried to make the article suitable for beginners (if you read it, please tell me if it works for you )
I've been using them with VC6 and VC8, so VC2003 should be no problem. But if boost is still to intimidating, there are many other smart pointer implementations. I recommend boost because they are well designed, flexible, but still fairly simple (a good balance).
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers! We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP Linkify!|Fold With Us!
|
|
|
|
|
sorry, I thought that would be usefull.
thanks for the heads up.
|
|
|
|
|
How do I split doc into pages for printing? I have a long multiline string that I want to print. How do I calc number of pages needed to print it? How do I call OnDraw for specific page?
An example would be great.
|
|
|
|
|
Hello all.Any body know how i can create toolbaar in my application??
Please if possible then send me code..
Thank you very much..
Shah Satish..
|
|
|
|
|
|
|
How can I programmatically change setting in Local Area Connection property using C++ application?
I need to uncheck some property and then check it back. For example File and Printer Sharing for Microsoft Networks.
Thank you.
Ilya
-- modified at 16:03 Wednesday 20th December, 2006
|
|
|
|
|
If you getting error like that
error C2872: 'IXMLDOMParseErrorPtr' : ambiguous symbol
could be 'c:\program files\microsoft visual studio 8\vc\include\comdefsp.h(1263) : _com_ptr_t<_IIID> IXMLDOMParseErrorPtr'
1> with
1> [
1> _IIID=_com_IIID<ixmldomparseerror,& _guid_3efaa426_272f_11d2_836f_0000f87a7782="">
1> ]
1> or '.\debug\msxml3.tlh(250) : MSXML2::IXMLDOMParseErrorPtr'
What would be correct resolution
1. instead of
IXMLDOMParseErrorPtr spErr = pXMLDom->parseError;
use
::IXMLDOMParseErrorPtr spErr = pXMLDom->parseError;
Or use
MSXML2::IXMLDOMParseErrorPtr spErr = pXMLDom->parseError;
|
|
|
|
|
|
i don't know if it's your case, but it's commonly bad practice to use a using namespace directive, because of such problems of ambiguousness...
|
|
|
|
|
I know, man I know. It was too many places to correct, so I was trying to be smart as
I found that decls. in comdef is different than in msxml*.tlh, so I decided not to use defaults.
Thanks, anyway.
|
|
|
|