As it takes about a 90 - 120 second to write, I would like to have it
in a worker thread. To that purpose I have called AfxBeginThread with
Appoint,GetSafeHwnd(),THREAD_PRIORITY_LOWEST as the arguments.
I have UINT (__CDECL) Appoint(void) declared at the top of the
Try2DLG.cpp file and the function is as per MSDN initialised as
UINT __cdecl Appoint(LPVOID pParam){
//work code...........
}
The fault I get is:
error C2665: 'AfxBeginThread' : none of the 2 overloads can convert
parameter 1 from type 'unsigned int (__cdecl *)(void)'
The error message look much like the function is seen by the compiler
as a pointer to a function - I do not see how that comes about.
Please have you any suggestions. I can get the whole lot working
easily using the code in InitDialog but then the client have to wait
for some 2 minutes before anything appears on the screen. I agree that
this only happens at first install - but even so I need and want to
know about worker threads.
I think I have followed MSDN and all my books, dotting the i's and
crossing the t's and I have given it a full 8 hours - jolly glad I am
not doing this for a living - PLEASE HELP.
UINT Appoint(LPVOID pParam){
}
Borge H. Pedersen <bo...@NOSPAMiinet.net.au> wrote in message
news:39223b67...@news.m.iinet.net.au...
> I have a function. Happens to be called Appoint. It returns nothing
> and takes no arguments. Its function is to make a calendar table in a
> database. It will add the times of availability of professionals in
> 1/4 hour intervals on certain days - in fact an appointment book.
>
> As it takes about a 90 - 120 second to write, I would like to have it
> in a worker thread. To that purpose I have called AfxBeginThread with
> Appoint,GetSafeHwnd(),THREAD_PRIORITY_LOWEST as the arguments.
>
> I have UINT (__CDECL) Appoint(void) declared at the top of the
> Try2DLG.cpp file and the function is as per MSDN initialised as
>
> UINT __cdecl Appoint(LPVOID pParam){
> file://work code...........
Thread function must be global, or static member of a class.
HTH,
David Wilkinson
=======================
"Borge H. Pedersen" wrote:
>
> I have a function. Happens to be called Appoint. It returns nothing
> and takes no arguments. Its function is to make a calendar table in a
> database. It will add the times of availability of professionals in
> 1/4 hour intervals on certain days - in fact an appointment book.
>
> As it takes about a 90 - 120 second to write, I would like to have it
> in a worker thread. To that purpose I have called AfxBeginThread with
> Appoint,GetSafeHwnd(),THREAD_PRIORITY_LOWEST as the arguments.
>
> I have UINT (__CDECL) Appoint(void) declared at the top of the
> Try2DLG.cpp file and the function is as per MSDN initialised as
>
> UINT __cdecl Appoint(LPVOID pParam){
I shall tonight have a look at Newcomers essay on Worker Threads -
will let you know if I succeed with that. Kruglinsky's fifth edition
is the book from which I have gleaned the most information - pity I
cannot make it work.
Some other books I have don't even mention threads. My number 3 son in
UK says that is the worst part of Java that he had to manage - good
for him that he is no good on Visual :-)
Casting a function call to be something with a different set of
parameters is very risky; interfaces are fussy that way. Note that you
declare the function in one way and implement it in another; under C++
rules, the forward declaration is the one that is seen (the one with
the void parameter), but the one that is actually there has an LPVOID,
meaning it is a completely different function. What you coded is
equivalent to this:
int f();
int proc()
{
return f(1);
}
int f(int j)
{
return j+1;
}
int proc2()
{
return f() + f(3);
}
which should complain that f(1) is not a valid function call, since
there is no function known (at that point in the program) which has
the name f and takes an integer argument. Under C++ rules, when it
encounters the second instance of f, that is an overloaded function,
so it won't report a conflict with the forward declarations. By the
time you get to proc2, however, both functions are known and the call
compiles. But when you link, it will report f() as an unresolved
external since we haven't actually defined it; we only promised it
would exist.
Read my essay on worker threads for other useful tricks, but the key
one is you really have to create the thread procedure according to the
spec, not just cast it.
joe
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www3.pgh.net/~newcomer
MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm
I'm not an expert about threads, but I've been just working with them and
the only difference between your declaration and the one that works with me
is the __cdecl statement. Maybe you should try without it, if it's not
mandatory for your function to work.
Bye. Sergio76
UINT RunThread(LPVOID ptr); //Declared in Header file
// the followind is in the InitDialog
CWinThread* pThread =
AfxBeginThread(RunThread,GetSafeHwnd(),THREAD_PRIORITY_LOWEST);
UINT RunThread(LPVOID ptr)
{
MyFunc();
return 0;
}
void MyFunc(void) { // static UINT MyFunc(void); // function outside
any classes.
That last bit is as important as getting the params right.
Making the function global worked.
Thanks to all for advise given.
I guess I really don't understand. What is your MyFunc() doing here? It
seems totally redundant. Why not just do your work in the thread
function RunThread() itself?
The usual reason for calling a secondary function is when you really
wanted to call a member function. To do this, pass the "this' pointer
rather than the window handle:
CWinThread* pThread =
AfxBeginThread(RunThread, this, THREAD_PRIORITY_LOWEST);
and make a static (or global, but static gives better "encapsulation")
thread function like this:
UINT RunThread(LPVOID ptr)
{
CMyClass* pClass=(CMyClass*)ptr;
return pClass->MyFunc();
}
Now UINT MyFunc() can be a member function and can access any member
variables of the class, in particular m_hWnd if this is a window class.
Remember however that this function is running in the worker thread, so
it must be aware of synchronization and MFC thread safety issues.
HTH,
David Wilkinson
==================
I shall play around with your suggestion as soon I get up in the
morning - it is now 10 pm and it promises to be a rowdy night from
what I hear in the street -- thanks for the response