|
|
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
|
|
|
|
|
great... thanks.
As a side note, I have to say THANKS to everyone at CodeProject, and everyone that uses CodeProject. I started using VC++ in September on my first real project at work. Coming from Visual Basic, I was a little intimidated making the transition, but CP has really made it less painless, and even enjoyable experience. Thanks for help everyone.
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
|
|
|
|
|
Marcus, I think there's a flaw in your piece of code. Instead of
CreateMutex( NULL, TRUE, "MVD Load Utility" ) you should use
CreateMutex( NULL, FALSE, "MVD Load Utility" ); Good luck.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
thanks. I read the MSDN on CreateMutex, but I can't make heads or tails of what the difference is.
BTW - in your previous example, how did you get the code to appear in beige?
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
|
|
|
|
|
thanks. I read the MSDN on CreateMutex, but I can't make heads or tails of what the difference is.
The difference is that when bInitialOwner is set to TRUE, the system gives ownership to the first process that creates the mutex, as if it has subsequently called WaitForSingleObject on the mutex handle. As ownership is not needed for your purposes (you are only resorting to mutexes as a convenient way to share global identifier across proceses), bInitialOwner is best left as FALSE (moreover, you'd have to expliciy call RelaseMutex later, which is not the same as closing the handle). Pff, what a messy explanation, hope you've understand something of it 
To get the beige background enclose your code between <pre> and </pre> tags.
Regards
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
If his program exits, he need not call ReleaseMutex as the mutex object itself gets destroyed [or am I highly erroneous here?]
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
"highly erroneous"? that sounds painful!
Sorry to dissapoint you all with my lack of a witty or poignant signature.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
