|
Do those DLLs do something weird at DLL_PROCESS_ATTACH or DLL_PROCESS_ATTACH time, like loading another libraries?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I'm not sure. They could very well be. I created those DLLs through
the MFC DLL Wizard. DllMain is hidden from me, so I don't know
exactly what it's doing.
Steve The Plant
|
|
|
|
|
If you used the MFC Wizard, that part should be OK.
(Wild guessing) Try statically linking MFC (if your DLLs and app used it as a shared DLL).
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Would you be able to post your code for loading and releasing the DLL's. What you are describing sounds weird. The only other things I can think off that would possibly affect you are that because they are extension DLL's they get loaded/released together, or the base address's of the dlls (set in the linker tab of settings) are clashing somehow.
Roger Allen
Sonork 100.10016
If I'm not breathing, I'm either dead or holding my breath.
|
|
|
|
|
Hi,
I'm trying to convert a line of code that calls the API CreateThread function to the _beginthreadex function, but I get the compile error:
"cannot convert parameter 3 from 'unsigned long (__stdcall *)(void *)' to 'unsigned int (__stdcall *)(void *)"
Parameter 3 is declared as type LPTHREAD_START_ROUTINE. What type should I use to avoid this compile error?
Thanks
Paul Jahans
|
|
|
|
|
Try using this sort of thread proc function :-
DWORD ThreadFunc(DWORD data)
{
//thread stuff in here
}
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
The thread function is in the calling program and is declared like this:
DWORD WINAPI CGUITermDoc::CommReader(void *pvData)
From calling program, I call the DLL function:
StartCommThread(LPTHREAD_START_ROUTINE CommProc, void *pvData)
In this function, I try to pass CommProc to the _beginthreadex function, but this is where I get the compile error.
Paul Jahans
|
|
|
|
|
|
Yes, that's it!
you are missing the static in your function definition.
(Just in case it was not clear yet!)
static UINT WINAPI CommReader(void *pvData);
|
|
|
|
|
Funny how almost 30% of questions asked here are already in the FAQ
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
Seems like _beginthreadex does not accept functions of type LPTHREAD_START_ROUTINE but rather functions with the signature (unsigned int (__stdcall *)(void *)) (i.e., returning unsigned int instead of DWORD ).
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
You cannot use a non-static member function of a class as your thread proc.
Nish
p.s. make it static, or make it a global function not part of any class
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
This doesn't answer your question, but might be of interest
From the docs for CWinThread:
"The CWinThread class is necessary to make your code and MFC fully thread-safe. Thread-local data used by the framework to maintain thread-specific information is managed by CWinThread objects. Because of this dependence on CWinThread to handle thread-local data, any thread that uses MFC must be created by MFC. For example, a thread created by the run-time function _beginthreadex cannot use any MFC APIs."
|
|
|
|
|
Tim
This is serious stuff.
This means we cannot use MFC functions and CRT functions together in any thread.
I mean to use CRT functions safely it is always advised to use _beginthreadex. Now you say MFC wont go along with that.
This is a bad situation
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
Nish [BusterBoy] wrote:
This means we cannot use MFC functions and CRT functions together in any thread.
No, that's incorrect. Look at the source for CWinThread::CreateThread() and you'll see that it calls _beginthreadex() .
The restriction on how you create the thread ensures that MFC is correctly initialized. Since MFC uses the CRT, MFC handles initializing the CRT itself.
--Mike--
My really out-of-date homepage
"Hey, you wanna go to the Espresso Pump and get sugared up on mochas?"
-- Willow Rosenberg
Sonork - 100.10414 AcidHelm
Big fan of Alyson Hannigan.
|
|
|
|
|
Okay, MIke.
But here is one more question!
Say I am writing a console based app [NT service] that uses MFC. Now can I use _beginthreadex to start my worker threads and expect to use MFC functions safely?
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
|
|
Hallo,
can anybody help me with CListView class?
1) I can use only one column with width on all view window. Problem is with scroll bar. I get the size of scroll bar in CListView::InitDialog using GetListCtrl().GetScrollBarCtrl()->GetWindowRect(). But at this time is not scroll bar known. So what is the good way?
2) I can't select any row in list control. I filter callbacks on mouse click but how about keyboard click?
3) I can't show header. I used GetListCtrl().SetExtendedStyle(LVS_NOCOLUMNHEADER); in the CListView::InitDialog but it has no effect.
Thanks, Alex.
Alex
|
|
|
|
|
I have been looking at this to I find this very annoying. If you don't have a header (unless you have more that one column or it won't work) don't insert a column and the only what it should scroll is if the contents is wider that the view.
Hopefully I was helpful or somebody has a better suggestion.
- Matt Newman
- Matt Newman
-Sonork ID: 100.11179:BestSnowman
|
|
|
|
|
1) I'm not sure I understood your question, but seems what you're after is calculating the width of the view minus the width of the vertical scrollbar so that you can adjust the column to its maximum extent without the horizontal scrollbar appearing. Am i right? If so, ::GetSystemMetrics(SM_CXVSCROLL) might be what you're looking for.
2) I don't quite understand your question. Sorry.
3) LVS_NOCOLUMNHEADER is not an extended style. Use GetListCtrl().ModifyStyle(0,LVS_NOCOLUMNHEADER,TRUE) instead.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I'm using the code from following posting to avoid running multiple instances of my app. I'm running an MFC SDI application. Where is the ideal location to create and release the mutex?
//=======================================================
Subject: Re: Avoiding multiple instances of an application.
Sender: John Uhlenbrock
Date: 15:53 7 Aug '01
I've seen a few examples to avoid multiple instances of an application. In fact, there are a few of them here on code project. However, they all seem like a lot of code, when there is an easy solution like:
HANDLE hMutex = CreateMutex( NULL, TRUE, "MVD Load Utility" );
if( (hMutex == NULL) || (GetLastError() == ERROR_ALREADY_EXISTS) )
{
AfxMessageBox( "Two copies of this program are not allowed to run at the same time." );
return FALSE;
}
Marcus
Make no little plans; they have no magic to stir your blood to action. Make big plans, aim high in work and hope
-- Daniel Burnham
|
|
|
|
|
CWinApp::InitInstance
Nish
p.s. Of course that will be the CWinApp derived class in your case...
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
Nish,
thanks for the quick response. do I make the mutex's handle a member of my CWinApp derived class. then how (and where) should I realease it?
Marcus
Make no little plans; they have no magic to stir your blood to action. Make big plans, aim high in work and hope
-- Daniel Burnham
|
|
|
|
|
No need to release it. The system does it for you when the program exits.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|