|
Richard gave you the right suggestion, then. The only trick part is computing the size of the raw data (you may find sample code at MSDN[^]).
Please note, as workaround, you could directly encode the whole BMP file (if you have it) content in Base64.
Veni, vidi, vici.
|
|
|
|
|
Hello,
I have a C# dll (COM) which contains API which have a parameter like below :
[type: ComVisible(true)]
[Guid("66F046BC-D97C-4CF2-96B5-01E66329FC65")]
[InterfaceType(ComInterfaceType.InterfaceIsDual)]
public interface ICDBrowserServiceMgr
{
[DispId(15)]
void Initialize(SeeSPMPLMClientLib.TSeeSPMPLMClient A_pClient);
...}
Now I need to integrate this dll in MFC application
So I put the import directive
#import "SeeSPMPLMClient.dll"
#import "My_dll.tlb"
after i do
My_Dll_Namespace::ICDBrowserServiceMgrPtr m_pICDBrowser;
SeeSPMPLMClientLib::ISeeSPMPLMClientPtr m_pPLMClientMgr;
m_pICDBrowser->Initialize(m_pPLMClientMgr);
I ahve the error :
error C2664: 'My_Dll::ICDBrowserServiceMgr::Initialize' : cannot convert parameter 1 from 'SeeSPMPLMClientLib::ISeeSPMPLMClientPtr' to 'My_Dll_Namespace::ISeeSPMPLMClient *'
Any idea please ?
modified 10-Jan-14 4:34am.
|
|
|
|
|
khaliloenit wrote: Any idea please ?
As the message says, you cannot pass a SeeSPMPLMClientLib::ISeeSPMPLMClientPtr to a method that expects a My_Dll_Namespace::ISeeSPMPLMClient *. Check the documentation and the header files to see exactly what you should be passing across.
Veni, vidi, abiit domum
|
|
|
|
|
as you see above
the API take as parameter the same type which I pass from C++ !!!
|
|
|
|
|
Er, No; otherwise the compiler would not be producing that error message.
Veni, vidi, abiit domum
|
|
|
|
|
this is cant be caused by ambiguity of namespaces ?
i.e : if this type is used in C# dll and after passed from other project which use same type we have ambiguity of Type ?
|
|
|
|
|
As I said before, you need to look at the .tlb and .h files to check exactly what object you should be passing.
Veni, vidi, abiit domum
|
|
|
|
|
m_pICDBrowser is a variable of a type defined in the namespace My_Dll_Namespace, therefore the method Initialize is also defined in that namespace, and, according to the compiler error message, expects an argument of pointer to a type that's also defined in that namespace.
You however pass an argument that's defined in an entirely different namespace, SeeSPMPLMClientLib - it's a different type.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
As you see above I pass the same type :
public interface ICDBrowserServiceMgr
{
[DispId(15)]
void Initialize(SeeSPMPLMClientLib.TSeeSPMPLMClient A_pClient);
...}
and in call
SeeSPMPLMClientLib::ISeeSPMPLMClientPtr m_pPLMClientMgr;
m_pICDBrowser->Initialize(m_pPLMClientMgr);
|
|
|
|
|
You're missing my point. Check the type of
m_pICDBrowser ! the function
Initialize() you are calling here is not the one you think you are calling!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Not understand , please can you explain more ?!!
|
|
|
|
|
Maybe it's best you take another look at the error message you got. In the line
m_pICDBrowser->Initialize(m_pPLMClientMgr);
the error message states that it cannot convert the first parameter in the call (m_pPLMClientMgr to the type that the function expects.
According to the error message, the type of m_pPLMClientMgr is SeeSPMPLMClientLib::ISeeSPMPLMClientPtr, but the type it expects is My_Dll_Namespace::ISeeSPMPLMClient *.
This implies, that you have a type ISeeSPMPLMClientPtr defined somewhere in namespace SeeSPMPLMClientLib, but it is not defined as the required type My_Dll_Namespace::ISeeSPMPLMClient *.
I suspect that you mixed up the two namespaces. Maybe you inserted a using namespace somewhere (always a bad idea), and then you no longer saw what namespace the definitions and types refer to, or maybe you just have a wrong type definition.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
i have program and i believe that it works fine under debug mode, the program does not have memory leak or any other leaks, what happened that i switched to release mode, and somehow i see weird problems showing up
1- the free and calloc work fine but sometime the program crash tells me a heap corruption issue, where as each pointer is checked, when i look at task manger the program works with regular around 10mg, but somehow it gets increased to 1gb1! and this happens after the crash
2- when i use openfile function the api one, it works fine then somehow the window gets busted? such lists or prarts from openfile disperse?
i do not believe it's related to uninitialized data cuz all the variables are initialized even the pointers
i did check with all leak tools and non of them show memory leak, i did see access violation but it's also handled with exceptions
i do not understand why it's still crashing whereas i checked everything? any ideas or similar issues?
|
|
|
|
|
Given how little you have told us about how you handle the data or even what the program does, it's really hard for us to say what is wrong.
It is possible that you simply keep creating objects and adding them to a list, which has functionality for deleting all the objects when the list is destroyed. If that is the case, you don't have memory leaks, you just don't release memory until the program shuts down. You mention that you don't see failures in the debug build, but that could be because the release build is able to allocate objects at a much higher rate than the debug build.
Like I said, this is just one possibility.
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
thanks for your time,
which has functionality for deleting all the objects when the list is destroyed. If that is the case, you don't have memory leaks, you just don't release memory until the program shuts down
can you explain what does release memory mean? i know that free it does release the memory, and yes i do have one array it's 2d char pointer array...
|
|
|
|
|
Deleting allocated objects is the same as releasing the memory used for the objects. It's just a different way of saying the same thing.
Alright, so you have an array. What is the purpose of that array? Do you expand it array with data you read from somewhere?
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
yes using realloc, and i do check the pointers each time, and i do add 1 for the null in the end? but it does not show any error, actually i have feelings that this 2d array makes so many issues
|
|
|
|
|
Memory leaks did not lead to crashes. They just block memory. Your program corrupts the heap and generates access violations. Handling access violations by exceptions does not help. When they occur, your program is in an undefined state. So you must find the source code that corrupts the heap and generates the access violation.
Common sources are invalid pointers or array indexes and don't checking error returns. You can try to execute only portions of your program and check if corruptions occur to narrow down the source code that contains the error. Best practice to avoid such errors is using asserts in debug build that check all function parameters and return values.
|
|
|
|
|
thanks for your time, gonna try assert
|
|
|
|
|
Note that you can change the options for your release build to also create debug information. That way you can debug your release build and thus analyze what's happening. The only difference to your "true release" build will be performance - but your problem doesn't sound like it's caused by a program that is running "too fast".
"release" and "debug" are just terms commonly used by IDEs to declare a set of build options most suitable for debugging or releasing an application, respectively. But you can change these options or create a third set in any way you like.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
thanks for your time, i already done that 
|
|
|
|
|
|
|
jone20132 wrote: i did see access violation but it's also handled with exceptions
A memory access violation? If so then you do not "handle" that with exceptions.
|
|
|
|
|
thanks, i do "handle" the exceptions as i mentioned before, the reason why i saw the access violation that i turned them on....
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
