|
Hi Naveen,
You are correct. But I have tested that even if I removed WINAPI, the same error at the same line.
Any ideas?
regards,
George
|
|
|
|
|
George_George wrote: You are correct. But I have tested that even if I removed WINAPI, the same error at the same line.
because you're doing it wrong.
what did I say to you yesterday ?[^]
to Remove __stdcall declared before the return type (and that was the subject of your question yesterday!!!).
why do you still do it wrong ?
also, please edit your 1st post in this thread. the long line in the pre tag is breaking the formatting.
|
|
|
|
|
Hi toxcct,
I removed WINAPI, I think the effect should be the same, correct?
regards,
George
|
|
|
|
|
George_George wrote: I removed WINAPI, I think the effect should be the same, correct?
GOD NO !
the place of the calling convention is important !!!!
it shall be after the return type. so in brief, let WINAPI, and remove the other (which is moreover the same as WINAPI)
|
|
|
|
|
Hi toxcct,
I think the following two lines are the same. Seems you do not agree?
BTW: WINAPI is defined to be __stdcall.
extern "C" __declspec(dllexport) BOOL WINAPI StoreData(DWORD dw)
extern "C" __declspec(dllexport) BOOL __stdcall StoreData(DWORD dw)
regards,
George
|
|
|
|
|
George_George wrote: I think the following two lines are the same. Seems you do not agree?
yes, they are identical.
what I was complaining at was about the following 2 lines:
extern "C" __declspec(dllexport) __stdcall BOOL WINAPI StoreData(DWORD dw)
extern "C" __declspec(dllexport) BOOL WINAPI StoreData(DWORD dw)
|
|
|
|
|
Thanks toxcct,
I understand your point now.
regards,
George
|
|
|
|
|
Your dll function follows the standard calling convention (__stdcall) but you didn't add that in the typedef of the functions of your executable. Add the __stdcall in the typedef also, this should fix the problem (or the WINAPI, which is the same thing).
|
|
|
|
|
Hi Cedric,
Using __stdcall in function pointer typdef will cause compile error. Here it is. Any ideas?
typedef BOOL __stdcall (*StoreDataFp)(DWORD);
1>d:\visual studio 2008\projects\testdll\testdllclient\main.cpp(11) : error C2059: syntax error : '('
1>d:\visual studio 2008\projects\testdll\testdllclient\main.cpp(21) : error C2065: 'StoreDataFp' : undeclared identifier
1>d:\visual studio 2008\projects\testdll\testdllclient\main.cpp(21) : error C2146: syntax error : missing ';' before identifier 'StoreData'
1>d:\visual studio 2008\projects\testdll\testdllclient\main.cpp(21) : error C2065: 'StoreData' : undeclared identifier
1>d:\visual studio 2008\projects\testdll\testdllclient\main.cpp(21) : error C2065: 'StoreDataFp' : undeclared identifier
1>d:\visual studio 2008\projects\testdll\testdllclient\main.cpp(21) : error C2146: syntax error : missing ';' before identifier 'GetProcAddress'
1>d:\visual studio 2008\projects\testdll\testdllclient\main.cpp(25) : error C3861: 'StoreData': identifier not found
regards,
George
|
|
|
|
|
You have to put it inside the parenthesis. See here[^] for example.
|
|
|
|
|
Thanks Cedric,
I have tried your solution works. It is good to learn from you that we also need calling convention for function pointer definition.
regards,
George
|
|
|
|
|
I suggest you read a bit more about calling conventions to understand what it is exactly (basically, this defines who, of the caller or the callee, will clean the stack after the function terminates). By default, C++ uses a __cdecl calling convention. In your dll, you explicitely stated that your functions should follow the __stdcall convention. If in your executable (in your typedef), you don't specify that the function uses a __stdcall calling convention, there's no way for your executable to know that, so it will uses the __cdecl as usual, thus your crash.
|
|
|
|
|
Thanks for your advice, Cédric!
I did not know for function pointer, we also need to define calling convention as well.
regards,
George
|
|
|
|
|
In fact it is logical when you think a bit about it. Your function is in your dll and you use it by calling LoadLibrary and GetProcAddress. To load the function you use a typedef in your exe to specify how the function looks like, this is the only way for your exe to know the function. So, if you don't specify on the function typedef that the function uses a __stdcall calling convention, the exe has no way of knowing that information.
|
|
|
|
|
Thanks Cédric,
Your description is very reasonable.
regards,
George
|
|
|
|
|
Hi Experts,
How can I traverse System Volume Information folder?
I also got the solution "You have to take ownership of the directory and its objects before you can enumerate them."
But how can I do that?
|
|
|
|
|
Didn't you ask this yesterday?
Iain.
|
|
|
|
|
|
Did you try do do it from the command line as I suggested?
|
|
|
|
|
Sir, But I want to do it programatically.
|
|
|
|
|
You'll have to read up on ACLs (Access Control Lists), search for it here on CP. There are some good articles.
|
|
|
|
|
I can load a BMP file into a CBitmap object.
The number of bits per pixel of image is 32.
How to change the number of bits per pixel to 16?
|
|
|
|
|
|
Hi,
I have an ActiveX component that I build using MFC. I use this component in my C# application. Every time I close my C# application, it generated this error:
Debug Assertion Failed!
Program: ...
File: f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp
Line: 1007
etc..
etc..
etc..
I do the debugging and it fails on this line:
#ifdef _DEBUG
ASSERT(pMap->LookupPermanent(hWndOrig) == NULL);
#endif
I know it is not an important question, because if it is in release, it works perfectly.
But I was wondering, what can cause this problem?
Please note:
1. This error only occurs on my specific application.
2. When I build a new C# application. It works fine.
Any idea?
|
|
|
|
|
RYU^^ wrote: I know it is not an important question, because if it is in release, it works perfectly.
Probably not.
The ASSERT macro is disabled when you're building for release, which means that the problem is only disguised in release mode.
If you have a look at the surrounding comments in the wincore.cpp file, you'll find that this assertion is due to that the window handle has not been detached from the object handle map. When you use wizards to generate code for your application, as I assume you have, this assertion won't be triggered by the generated code. My point is that this is something else and I would bet my money on COM-related stuff.
If you put some breakpoints to check which window it is that's causing problems, I would expect it to be an unknown window from your point of view.
Some things to check up on:- Make sure that you release all interface references to your ActiveX when the application is closed.
- Make sure you calling
::CoUninitialize() for each time you've called ::CoInitialize() or similar. - If you're using a secondary thread that operates on the ActiveX, you have to set up the COM library for that thread as well by calling
::CoInitialize() / ::CoUninitialize() . Remember that you also have to marshal the interfaces to the secondary thread.
You may find this article[^] to be interesting as well.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote "High speed never compensates for wrong direction!" - unknown
|
|
|
|