|
If you are using resource editor, you can set the tab order there. It is available in "Layout" menu in VC6 and "Format" menu VC9. Shortcut key is Ctrl + D (in VC6 keyboard shortcut map). Then you can see the tab order indication for all controls. You can click on each controls to sequence.
If you are creating the controls dynamically, the creation order sets the tab order. You can change it by using SetWindowPos().
|
|
|
|
|
I want to be able to #define CSHARP if the dll detects a c# app, and not define it if its c++
if there is another way of doing it I would be open to that as well... I just cannot afford the time it takes to change this each time i build it with a different application
#define CSHARP
#ifdef CSHARP
typedef void (__stdcall *callBack)(unsigned char* buffer, int size);
#else
typedef void ( *callBack)(unsigned char* buffer, int size);
#endif
|
|
|
|
|
Greg Mort wrote: Using a C++ dll in C++ project and a C# project... C# requires __stdcall c++ does not... is there a way the dll can determine who is using him?
Do you build two versions of the same DLL? Really?
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]
|
|
|
|
|
<blockquote class="FQ"><div class="FQA">CPallini wrote:</div>Do you build two versions of the same DLL? Really?</blockquote>
yes
C#, C++ <- windows and XP
|
|
|
|
|
I don't get you: C++ can call __stdcall functions.
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]
|
|
|
|
|
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 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
