|
CPallini wrote: I don't get you: C++ can call __stdcall functions.
agreed, however in this instance that is not going to be possible
therefore, I am asking if there is a way to detect who is using the dll, or another way
|
|
|
|
|
Greg Mort wrote: agreed, however in this instance that is not going to be possible
Why?
Greg Mort wrote: therefore, I am asking if there is a way to detect who is using the dll, or another way
Of course there is no way to determine, at compile time, the kind of programming language used to build the application the DLL will be linked to.
I believe I keep missing the point: if you really (I strongly doubt about...) need to maintain two different configurations of the DLL, cannot you just define these configurations in Visual Studio?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
yup def. missing the point... there are not two configurations, nor is this a sole thing to do with visual studio
read the thread below, it should make sense
like the other guy said, which is what i presumed the answer has always been, there is no true way to detect who is using a dll at compile because the code is already compiled, and nos not who is using it, its just a file, that is interpreted by another program...
one way to do this is to just make two separate functions, that then in turn use the same function inside of that dll
and the program must just call the appropriate function
|
|
|
|
|
I read that and the callback argument doesn't convince me. Could you provide a sample?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
i dont think i understand what you are asking?
|
|
|
|
|
I believe the C++ application can use __stdcall (hence the same DLL for both C++ and C# applications, no need to detect whatever). You said it's not possible due to use of callbacks. Such an argument make no sense to me.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Why don't you simply make the function a stdcall function ? This is perfectly valid as long as it is defined as a stdcall function in your C++ application also.
This way, you don't need two versions of your dll.
|
|
|
|
|
Cedric Moonen wrote: Why don't you simply make the function a stdcall function ? This is perfectly valid as long as it is defined as a stdcall function in your C++ application also.
This way, you don't need two versions of your dll.
its not working with a callback
so this is why i am asking if there is a way to determine who is using the dll
|
|
|
|
|
What do you mean ? You need to pass this function to a third party (for instance the win32 API) ?
Could you give a bit more information about what you are trying to do ? It feels like you are doing something wrong here...
|
|
|
|
|
Ok, got it working the way you said... but still would like the question answered if it is possible for a dll to know what is communicating with it
yes I had to have the function that was the call back properly defined...
|
|
|
|
|
Greg Mort wrote: but still would like the question answered if it is possible for a dll to know what is communicating with it
I don't know if there's a way at runtime to determine it but at compile time it is certainly not possible: your dll can be used by any program written in any language, so the compiler cannot guess at compile time who will be using it at runtime. The #define you wrote are used at compile time only and your function is exported at compile time also.
|
|
|
|
|
Cédric
Can't you drop into ASM and check the call stack return IP, then check the instruction immediately following the return. It should be an "add esp,xxx" (where xxx is the length of the arguments) if this is in fact a C++ call instead of STDCALL.
This is a really big kludge, but it should be able to be done.
Dave.
|
|
|
|
|
Dave,
That's maybe possible (my knowledge of ASM is a bit limited here) to determine the type of your function at runtime the way you did, but it is a bit useless, since you already know it (you wrote the function yourself when creating the dll).
Furthermore, it is still at runtime. There's no way at compile time to create a function that will be either a stdcall or a cdecl function depending of the type of application which is loading your dll.
|
|
|
|
|
Cédric,
I'm primarily a MASM developer, that is why I suggested it. In MASM you can control how you return, either a ret (n) for stdcall or a ret (0) for C++.
Dave.
modified on Thursday, October 29, 2009 11:38 AM
|
|
|
|
|
They are two different languages.
The fact that you can compile the same file in both is because the syntax happens to be similar.
So you cannot determine the language in code.
|
|
|
|
|
Hey guys,
I got a weird problem with a CFileDialog in an own thread.
It looks like the following:
static UINT Thread(LPVOID pParam)
{
CFileDialog dlg(true);
dlg.DoModal();
return 0;
}
...
AfxBeginThread(Thread, this);
When I c+p files or delete files in the file dialog I will get an Access Violation, as soon as the thread ends.
I told the debugger to break on Access Violations and this is the position where he stops:
At the file "threadex.c" in the function "void __cdecl _endthreadex (unsigned retcode)" at
ExitThread(retcode);
}
Anybody there, who can help me? ^^
There is nothing else in the code. Just a single dialog box with a button, which starts the thread in its OnButtonPressed() routine.
I am using VS2k8 SP1. I also already tried to use a gui thread instead of a worker thread, no changes.
Greets,
|
|
|
|
|
You shouldn't touch the GUI (opening a modal dialog for instance) in a different thread than the main thread. Why do you want to open the CFileDialog in a separate thread ?
|
|
|
|
|
I need to initialize COM objects in the main thread with a multithreaded apartment.
This deactivates things like D+D, C+P, Deletion of files, custom context menu and file type changing in file dialogs.
The only workaround I know, is to start the file dialog in a different thread.
|
|
|
|
|
Hi,
Just so I understand correctly you have called CoInitializeEx(COINIT_MULTITHREADED) in your main thread and therefore cannot use the CFileDialog because of the issue described in:
INFO: Calling Shell Functions and Interfaces from a Multithreaded Apartment[^]
Have you tried deriving the second thread from CWinThread and explicitly switching to single-threaded apartment?
Best Wishes,
-David Delaune
|
|
|
|
|
This solved my problem. Thanks...
I cant image, why I never tried this up till now 
|
|
|
|
|
slaindevil wrote: This solved my problem. Thanks...
No problem. I believe your thread was inheriting the threading model of the thread that created it.
Best Wishes,
-David Delaune
|
|
|
|
|
slaindevil wrote:
The only workaround I know, is to start the file dialog in a different thread.
Why not do the opposite - spawn a UI-thread that creates the MTA?
All you need is a message pump and something, e.g. a user defined message, that tells the thread to create the server that should reside in the MTA.
If your post is about the issue Randor mentions, you won't pull the rug for the main thread and all calls to shell functions will not fail because if the MTA at least.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Thanks for your idea, but Randors post solved my problem and it fits better into the program code. But really, thanks anyway!
|
|
|
|
|
I created a Gdiplus::Bitmap by Gdiplus::Bitmap::FromHICON(), but the alpha channels lost. Is there any solutions?
Evil.Ghost
|
|
|
|
|
Yes.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
