|
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]
|
|
|
|
|
The project style guidelines say this:
"Unless portability and reusability is not a concern, the use of standard integral types is forbidden (exception: enum) and the types from a standard project header must be used."
I can remember the days when we used to do this, but it has fallen into disuse. Are integers more portable now? I remember it being a problem with DEC machines, but we don't use them anymore. It seems I am not following the guidelines right now, I need a good reason in case the code inspectors ask.
In help all it says is that integer size is machine dependent.
------------------<;,><-------------------
|
|
|
|
|
RedSonja wrote: In help all it says is that integer size is machine dependent.
Well, that's an hint.
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 am aware that different machines have different sizes for integer. I was hoping to hear something like - compilers are so clever nowadays they can handle this.
It seems there is no way out and I will have to make a header file with standard types in it. I might have one left from 10 years ago. I was just hoping this kind of stuff was no longer necessary.
(I just surprised the new graduate, who wanted to know what an unsigned character is good for. Apart from using it as an unsigned character, in the old days when size mattered we used to use unsigned char to get an 8-bit integer. That was in image processing, with one integer for each pixel, etc.)
------------------<;,><-------------------
|
|
|
|
|
RedSonja wrote: compilers are so clever nowadays they can handle this.
Well, they are compilers after all (i.e. How 'the fresh Hell' a compiler would handle that?).
RedSonja wrote: (I just surprised the new graduate, who wanted to know what an unsigned character is good for. Apart from using it as an unsigned character, in the old days when size mattered we used to use unsigned char to get an 8-bit integer. That was in image processing, with one integer for each pixel, etc.)
Since there is a rather general agreement among different machines about the size of a byte, then it may be indeed a good starting point.
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
