Thread Problems

Found this from MSDN->codeguru, can't seem to figure out the problem....

class ThreadClass {
protected:
	HANDLE m_hThread; //Thread handle
	bool m_bActive; //activity indicator
	DWORD m_lpId; //Thread ID
public:
	ThreadClass(){}
	virtual ~ThreadClass(){Kill();}
	//Thread Management
	bool CreateNewThread() {
		m_hThread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)_ThreadFunc, 
(LPVOID) this, 0, (LPDWORD) &m_lpId);
		if (m_hThread == NULL) return false;
		m_bActive = true;
		return true;
	};
	//Wait for thread to end
	bool Wait() {return (WAIT_OBJECT_0 == WaitForSingleObject(m_hThread, 
INFINITE));}
	bool Suspend(){
		 m_bActive = false;
		 return(-1 != SuspendThread(m_hThread));
	};
	//Suspend the thread
	bool Resume() {
		m_bActive = true;
		return(-1 != ResumeThread(m_hThread));
	};
	 //Resume a suspended thread
	bool Kill() {return TerminateThread(m_hThread, 1);}
	//Terminate a thread
	bool IsActive() {return m_bActive;}
	 //Check for activity
	//override these functions in the derived class
	virtual void ThreadEntry(){ }
	virtual void ThreadExit(){ }
	virtual void Run(){ }
	 //a friend
	friend DWORD  WINAPI _ThreadFunc(LPVOID  pvThread);
};

DWORD  WINAPI _ThreadFunc(LPVOID  pvThread) {
	ThreadClass* pThread = (ThreadClass*)pvThread;  //typecast
	pThread->ThreadEntry(); //initialize
	pThread->Run();
	pThread->ThreadExit(); //finalize
	return 0;
};



class MyThread :: public ThreadClass
{
 virtual void ThreadEntry()
 {
  //Initialize
 }

 virtual void ThreadExit()
 {
  //Finalize
 }

 virtual void Run()
 {
  //do something
 }
};
 

0
roger8087 (31)
2/22/2008 2:31:30 AM
vc.mfc 33608 articles. 0 followers. Follow

9 Replies
642 Views

Similar Articles

[PageSpeed] 31

"Roger Rabbit" <roger@rabbit.com> wrote in message 
news:7E2C595C-E864-44BE-8330-05525CC33414@microsoft.com...
> Found this from MSDN->codeguru, can't seem to figure out the problem....

What is the problem? 

0
nobody1239 (10)
2/22/2008 5:04:24 AM
The core problem is that this will not work with MFC, so you can forget that you ever saw
it.

You *must* use AfxBeginThread or CWinThread::Create to create a thread class in MFC.  This
does not do that, and therefore is inherently flawed.  It will cause immense grief.  If
you were not using MFC, it would have to use _beginthreadex to be correct.  Assume it is
irrelevant to anything you will ever want to do; use CWinThread instead.
\More below...
On Thu, 21 Feb 2008 18:31:30 -0800, "Roger Rabbit" <roger@rabbit.com> wrote:

>Found this from MSDN->codeguru, can't seem to figure out the problem....
>
>class ThreadClass {
>protected:
>	HANDLE m_hThread; //Thread handle
>	bool m_bActive; //activity indicator
>	DWORD m_lpId; //Thread ID
>public:
>	ThreadClass(){}
>	virtual ~ThreadClass(){Kill();}
>	//Thread Management
>	bool CreateNewThread() {
>		m_hThread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)_ThreadFunc, 
>(LPVOID) this, 0, (LPDWORD) &m_lpId);
****
At this point, it is obvious this class is trash, and should never be used in MFC.  You
can stop as soon as you see this, and throw the whole thing out.

Had it been coded correctly, it would have be written as ::CreateThread.
****
>		if (m_hThread == NULL) return false;
>		m_bActive = true;
****
m_bActive seems redundant.
****
>		return true;
>	};
>	//Wait for thread to end
>	bool Wait() {return (WAIT_OBJECT_0 == WaitForSingleObject(m_hThread, 
>INFINITE));}
****
This is of marginal value.  It should be written as ::WaitForSingleObject, but it serves
little purpose.
***
>	bool Suspend(){
>		 m_bActive = false;
>		 return(-1 != SuspendThread(m_hThread));
>	};
****
This method should not exist, because it is an inherently bad idea to consider calling
SuspendThread (which, if it were actually being used, should have been coded as
::SuspendThread)
****
>	//Suspend the thread
>	bool Resume() {
>		m_bActive = true;
>		return(-1 != ResumeThread(m_hThread));
>	};
>	 //Resume a suspended thread
>	bool Kill() {return TerminateThread(m_hThread, 1);}
****
This is such an amazingly poor piece of code that it MUST be rewritten!  You should NEVER
call ::TerminateThread.  This class was probably written by someone who knew very little,
if anything, about threading.
****
>	//Terminate a thread
>	bool IsActive() {return m_bActive;}
>	 //Check for activity
>	//override these functions in the derived class
>	virtual void ThreadEntry(){ }
>	virtual void ThreadExit(){ }
>	virtual void Run(){ }
>	 //a friend
>	friend DWORD  WINAPI _ThreadFunc(LPVOID  pvThread);
****
This is nonsense and should be removed
****
>};
>
>DWORD  WINAPI _ThreadFunc(LPVOID  pvThread) {
>	ThreadClass* pThread = (ThreadClass*)pvThread;  //typecast
>	pThread->ThreadEntry(); //initialize
>	pThread->Run();
>	pThread->ThreadExit(); //finalize
>	return 0;
>};
****
This doesn't make any sense.  It wouldn't belong in a header file.  So what good is it
doing?  And why does it have a semicolon in it?
****
>
>
>
>class MyThread :: public ThreadClass
>{
> virtual void ThreadEntry()
> {
>  //Initialize
> }
>
> virtual void ThreadExit()
> {
>  //Finalize
> }
>
> virtual void Run()
> {
>  //do something
> }
>};
> 
****
You are best served by ignoring the existence of this class.  It is badly done,
fundamentally incorrect at several levels, and has at best severe negative value.
					joe
****
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15975)
2/22/2008 5:08:40 AM
The compiler chokes on the at the mythread declaration, I tried cleaning it 
up and reduced the error count 80% and now I am stuck. using VC 08 express. 
I gave up on the managed attempt, back to regular c++ which at least brings 
a large pool of skilled people together.

My goal was an easy to use class for threading. The first place I was going 
to use it was in the WM_PAINT_PROC methods I created to draw the screen. 
Figured it would be a good place to use a thread. I wish. I used the Win32 
calls and that's the place I am staying for now.

"Tom Walker" <nobody@example.com> wrote in message 
news:uw7TmBRdIHA.4728@TK2MSFTNGP03.phx.gbl...
> "Roger Rabbit" <roger@rabbit.com> wrote in message 
> news:7E2C595C-E864-44BE-8330-05525CC33414@microsoft.com...
>> Found this from MSDN->codeguru, can't seem to figure out the problem....
>
> What is the problem? 

0
roger8087 (31)
2/22/2008 5:40:41 AM
IN response to your private email:

What are you painting that takes so long that a thread is required?  Note that there are
valid cases where this can be so, but the example you sent me is trivial to the point of
irrelevance.

If you had a very, very complex image to develop, processing it in a thread can work, but
you need to demonstrate that there is a performance bottleneck related to drawing.

Also, since the WM_PAINT method comes into the main GUI thread, you have to somehow route
it to the secondary thread.  This means you cannot declare a PAINTSTRUCT and use
::BeginPaint, because that would have to be done in the thread that owns the window. For
that matter, it is not clear why you are doing this when CPaintDC would do it for you.

There were three major problems with your example; you said

void WM_PAINT_PROC(HWND hWnd)

If this were intended to be a thread function:
	1. The return type is erroneous
	2. The calling convention is erroneous
	3. The parameter is erroneous

The prototype for a thread function is EXPLICITLY stated in the documentation as

DWORD WINAPI ThreadProc(LPVOID)

and to change any one of these would result in a failure to compile.

But you should not be using CreateThread, and in using AfxBeginThread, the function
prototype is EXPLICITLY stated in the documentation as

UINT function(LPVOID)

and therefore the return type and parameter would be incorrect in your example, and result
in a failure to compile.

Note that you have done nothing to demonstrate that you are building a thread that
processes queued entries for drawing; the cost of creating a thread is not insignificant,
so you cannot be creating the thread each time you need to paint.  The overhead of thread
creation will probably dominate your drawing time.

If you had a long, complex painting task, you might consider something along the lines of

void CMyThread::OnDrawRequest(WPARAM wParam, LPARAM)
    {
     CPaintDC * dc = (CPaintDC *)wParam;
     while(something to do)
        {
          if(aborting painting)
              break;
          get next item in display list
          draw it
         }
      delete dc;
     }


void CMainThread::OnPaint()
    {
     CPaintDC * dc = new CPaintDC;
     drawingthread->PostThreadMessage(UWM_DRAW_REQUEST, (WPARAM)dc);
    }

But this is based on the premise that redrawing takes a very, very long time.
					joe

On Thu, 21 Feb 2008 21:40:41 -0800, "Roger Rabbit" <roger@rabbit.com> wrote:

>The compiler chokes on the at the mythread declaration, I tried cleaning it 
>up and reduced the error count 80% and now I am stuck. using VC 08 express. 
>I gave up on the managed attempt, back to regular c++ which at least brings 
>a large pool of skilled people together.
>
>My goal was an easy to use class for threading. The first place I was going 
>to use it was in the WM_PAINT_PROC methods I created to draw the screen. 
>Figured it would be a good place to use a thread. I wish. I used the Win32 
>calls and that's the place I am staying for now.
>
>"Tom Walker" <nobody@example.com> wrote in message 
>news:uw7TmBRdIHA.4728@TK2MSFTNGP03.phx.gbl...
>> "Roger Rabbit" <roger@rabbit.com> wrote in message 
>> news:7E2C595C-E864-44BE-8330-05525CC33414@microsoft.com...
>>> Found this from MSDN->codeguru, can't seem to figure out the problem....
>>
>> What is the problem? 
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15975)
2/22/2008 1:56:46 PM
Yes, my code is trivial for the example. Its just I am trying to lean how 
Windows ticks and it's numerous quirks. I tried pasting the AfxBeginThread 
into the search box in the IDE, page not found. Guess its back to yahoo etc.

"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
news:ksjtr35kd8qm0gr6maoa84tmmnv79uf0fv@4ax.com...
> IN response to your private email:
>
> What are you painting that takes so long that a thread is required?  Note 
> that there are
> valid cases where this can be so, but the example you sent me is trivial 
> to the point of
> irrelevance.
>
> If you had a very, very complex image to develop, processing it in a 
> thread can work, but
> you need to demonstrate that there is a performance bottleneck related to 
> drawing.
>
> Also, since the WM_PAINT method comes into the main GUI thread, you have 
> to somehow route
> it to the secondary thread.  This means you cannot declare a PAINTSTRUCT 
> and use
> ::BeginPaint, because that would have to be done in the thread that owns 
> the window. For
> that matter, it is not clear why you are doing this when CPaintDC would do 
> it for you.
>
> There were three major problems with your example; you said
>
> void WM_PAINT_PROC(HWND hWnd)
>
> If this were intended to be a thread function:
> 1. The return type is erroneous
> 2. The calling convention is erroneous
> 3. The parameter is erroneous
>
> The prototype for a thread function is EXPLICITLY stated in the 
> documentation as
>
> DWORD WINAPI ThreadProc(LPVOID)
>
> and to change any one of these would result in a failure to compile.
>
> But you should not be using CreateThread, and in using AfxBeginThread, the 
> function
> prototype is EXPLICITLY stated in the documentation as
>
> UINT function(LPVOID)
>
> and therefore the return type and parameter would be incorrect in your 
> example, and result
> in a failure to compile.
>
> Note that you have done nothing to demonstrate that you are building a 
> thread that
> processes queued entries for drawing; the cost of creating a thread is not 
> insignificant,
> so you cannot be creating the thread each time you need to paint.  The 
> overhead of thread
> creation will probably dominate your drawing time.
>
> If you had a long, complex painting task, you might consider something 
> along the lines of
>
> void CMyThread::OnDrawRequest(WPARAM wParam, LPARAM)
>    {
>     CPaintDC * dc = (CPaintDC *)wParam;
>     while(something to do)
>        {
>          if(aborting painting)
>              break;
>          get next item in display list
>          draw it
>         }
>      delete dc;
>     }
>
>
> void CMainThread::OnPaint()
>    {
>     CPaintDC * dc = new CPaintDC;
>     drawingthread->PostThreadMessage(UWM_DRAW_REQUEST, (WPARAM)dc);
>    }
>
> But this is based on the premise that redrawing takes a very, very long 
> time.
> joe
>
> On Thu, 21 Feb 2008 21:40:41 -0800, "Roger Rabbit" <roger@rabbit.com> 
> wrote:
>
>>The compiler chokes on the at the mythread declaration, I tried cleaning 
>>it
>>up and reduced the error count 80% and now I am stuck. using VC 08 
>>express.
>>I gave up on the managed attempt, back to regular c++ which at least 
>>brings
>>a large pool of skilled people together.
>>
>>My goal was an easy to use class for threading. The first place I was 
>>going
>>to use it was in the WM_PAINT_PROC methods I created to draw the screen.
>>Figured it would be a good place to use a thread. I wish. I used the Win32
>>calls and that's the place I am staying for now.
>>
>>"Tom Walker" <nobody@example.com> wrote in message
>>news:uw7TmBRdIHA.4728@TK2MSFTNGP03.phx.gbl...
>>> "Roger Rabbit" <roger@rabbit.com> wrote in message
>>> news:7E2C595C-E864-44BE-8330-05525CC33414@microsoft.com...
>>>> Found this from MSDN->codeguru, can't seem to figure out the 
>>>> problem....
>>>
>>> What is the problem?
> Joseph M. Newcomer [MVP]
> email: newcomer@flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm 

0
roger8087 (31)
2/22/2008 4:21:45 PM
OK is this call a better choice?

            AfxBeginThread(WorkerThreadProc,NULL,THREAD_PRIORITY_NORMAL,0,0,NULL);
	MessageBox("Thread Started"); // or just go back to something else

where I can change the thread priority to one of the various levels windows 
supports.

To start with I just wanted to thread the paint routine to lean how to do it 
generally. The whole industry is threading everything, I need to be able 
too.

Then after the paint routine, why not thread the about box too. Trivial I 
agree, but it's the algorithms I am need to learn.

"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
news:ksjtr35kd8qm0gr6maoa84tmmnv79uf0fv@4ax.com...
> IN response to your private email:
>
> What are you painting that takes so long that a thread is required?  Note 
> that there are
> valid cases where this can be so, but the example you sent me is trivial 
> to the point of
> irrelevance.
>
> If you had a very, very complex image to develop, processing it in a 
> thread can work, but
> you need to demonstrate that there is a performance bottleneck related to 
> drawing.
>
> Also, since the WM_PAINT method comes into the main GUI thread, you have 
> to somehow route
> it to the secondary thread.  This means you cannot declare a PAINTSTRUCT 
> and use
> ::BeginPaint, because that would have to be done in the thread that owns 
> the window. For
> that matter, it is not clear why you are doing this when CPaintDC would do 
> it for you.
>
> There were three major problems with your example; you said
>
> void WM_PAINT_PROC(HWND hWnd)
>
> If this were intended to be a thread function:
> 1. The return type is erroneous
> 2. The calling convention is erroneous
> 3. The parameter is erroneous
>
> The prototype for a thread function is EXPLICITLY stated in the 
> documentation as
>
> DWORD WINAPI ThreadProc(LPVOID)
>
> and to change any one of these would result in a failure to compile.
>
> But you should not be using CreateThread, and in using AfxBeginThread, the 
> function
> prototype is EXPLICITLY stated in the documentation as
>
> UINT function(LPVOID)
>
> and therefore the return type and parameter would be incorrect in your 
> example, and result
> in a failure to compile.
>
> Note that you have done nothing to demonstrate that you are building a 
> thread that
> processes queued entries for drawing; the cost of creating a thread is not 
> insignificant,
> so you cannot be creating the thread each time you need to paint.  The 
> overhead of thread
> creation will probably dominate your drawing time.
>
> If you had a long, complex painting task, you might consider something 
> along the lines of
>
> void CMyThread::OnDrawRequest(WPARAM wParam, LPARAM)
>    {
>     CPaintDC * dc = (CPaintDC *)wParam;
>     while(something to do)
>        {
>          if(aborting painting)
>              break;
>          get next item in display list
>          draw it
>         }
>      delete dc;
>     }
>
>
> void CMainThread::OnPaint()
>    {
>     CPaintDC * dc = new CPaintDC;
>     drawingthread->PostThreadMessage(UWM_DRAW_REQUEST, (WPARAM)dc);
>    }
>
> But this is based on the premise that redrawing takes a very, very long 
> time.
> joe
>
> On Thu, 21 Feb 2008 21:40:41 -0800, "Roger Rabbit" <roger@rabbit.com> 
> wrote:
>
>>The compiler chokes on the at the mythread declaration, I tried cleaning 
>>it
>>up and reduced the error count 80% and now I am stuck. using VC 08 
>>express.
>>I gave up on the managed attempt, back to regular c++ which at least 
>>brings
>>a large pool of skilled people together.
>>
>>My goal was an easy to use class for threading. The first place I was 
>>going
>>to use it was in the WM_PAINT_PROC methods I created to draw the screen.
>>Figured it would be a good place to use a thread. I wish. I used the Win32
>>calls and that's the place I am staying for now.
>>
>>"Tom Walker" <nobody@example.com> wrote in message
>>news:uw7TmBRdIHA.4728@TK2MSFTNGP03.phx.gbl...
>>> "Roger Rabbit" <roger@rabbit.com> wrote in message
>>> news:7E2C595C-E864-44BE-8330-05525CC33414@microsoft.com...
>>>> Found this from MSDN->codeguru, can't seem to figure out the 
>>>> problem....
>>>
>>> What is the problem?
> Joseph M. Newcomer [MVP]
> email: newcomer@flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm 

0
roger8087 (31)
2/22/2008 5:09:32 PM
Well, unless you have an *amazingly* complex picture to draw, this is probably a bad place
to use a thread.  

Playing with thread priorities is a guaranteed way to get into trouble nearly all the
time; it makes sense in some very restricted contexts, but you should make sure you are on
a multiprocessor before trying to play games with thread priority.

The paint routine is a poor choice for learning threading.

You should not bring up user-visible objects in a secondary thread.  Putting the About box
in a separate thread would be a very poor strategy for program development.

If you are looking for learning exercises for threading, interesting ideas deal with I/O
devices with unbounded blocking times (for example, serial ports), or situations in which
concurrency actually buys something (handling many queries at one time, each one of which
takes a lot of computation).

Painting is a poor choice in general, and take as given that it is a fundamentally Bad
Idea to put user-visible windows in any but the main GUI thread, and work from there.

Threading is very powerful, and very convenient, but the examples you chose are really
poor choices for a variety of reasons.
					joe

On Fri, 22 Feb 2008 09:09:32 -0800, "Roger Rabbit" <roger@rabbit.com> wrote:

>OK is this call a better choice?
>
>            AfxBeginThread(WorkerThreadProc,NULL,THREAD_PRIORITY_NORMAL,0,0,NULL);
>	MessageBox("Thread Started"); // or just go back to something else
>
>where I can change the thread priority to one of the various levels windows 
>supports.
>
>To start with I just wanted to thread the paint routine to lean how to do it 
>generally. The whole industry is threading everything, I need to be able 
>too.
>
>Then after the paint routine, why not thread the about box too. Trivial I 
>agree, but it's the algorithms I am need to learn.
>
>"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
>news:ksjtr35kd8qm0gr6maoa84tmmnv79uf0fv@4ax.com...
>> IN response to your private email:
>>
>> What are you painting that takes so long that a thread is required?  Note 
>> that there are
>> valid cases where this can be so, but the example you sent me is trivial 
>> to the point of
>> irrelevance.
>>
>> If you had a very, very complex image to develop, processing it in a 
>> thread can work, but
>> you need to demonstrate that there is a performance bottleneck related to 
>> drawing.
>>
>> Also, since the WM_PAINT method comes into the main GUI thread, you have 
>> to somehow route
>> it to the secondary thread.  This means you cannot declare a PAINTSTRUCT 
>> and use
>> ::BeginPaint, because that would have to be done in the thread that owns 
>> the window. For
>> that matter, it is not clear why you are doing this when CPaintDC would do 
>> it for you.
>>
>> There were three major problems with your example; you said
>>
>> void WM_PAINT_PROC(HWND hWnd)
>>
>> If this were intended to be a thread function:
>> 1. The return type is erroneous
>> 2. The calling convention is erroneous
>> 3. The parameter is erroneous
>>
>> The prototype for a thread function is EXPLICITLY stated in the 
>> documentation as
>>
>> DWORD WINAPI ThreadProc(LPVOID)
>>
>> and to change any one of these would result in a failure to compile.
>>
>> But you should not be using CreateThread, and in using AfxBeginThread, the 
>> function
>> prototype is EXPLICITLY stated in the documentation as
>>
>> UINT function(LPVOID)
>>
>> and therefore the return type and parameter would be incorrect in your 
>> example, and result
>> in a failure to compile.
>>
>> Note that you have done nothing to demonstrate that you are building a 
>> thread that
>> processes queued entries for drawing; the cost of creating a thread is not 
>> insignificant,
>> so you cannot be creating the thread each time you need to paint.  The 
>> overhead of thread
>> creation will probably dominate your drawing time.
>>
>> If you had a long, complex painting task, you might consider something 
>> along the lines of
>>
>> void CMyThread::OnDrawRequest(WPARAM wParam, LPARAM)
>>    {
>>     CPaintDC * dc = (CPaintDC *)wParam;
>>     while(something to do)
>>        {
>>          if(aborting painting)
>>              break;
>>          get next item in display list
>>          draw it
>>         }
>>      delete dc;
>>     }
>>
>>
>> void CMainThread::OnPaint()
>>    {
>>     CPaintDC * dc = new CPaintDC;
>>     drawingthread->PostThreadMessage(UWM_DRAW_REQUEST, (WPARAM)dc);
>>    }
>>
>> But this is based on the premise that redrawing takes a very, very long 
>> time.
>> joe
>>
>> On Thu, 21 Feb 2008 21:40:41 -0800, "Roger Rabbit" <roger@rabbit.com> 
>> wrote:
>>
>>>The compiler chokes on the at the mythread declaration, I tried cleaning 
>>>it
>>>up and reduced the error count 80% and now I am stuck. using VC 08 
>>>express.
>>>I gave up on the managed attempt, back to regular c++ which at least 
>>>brings
>>>a large pool of skilled people together.
>>>
>>>My goal was an easy to use class for threading. The first place I was 
>>>going
>>>to use it was in the WM_PAINT_PROC methods I created to draw the screen.
>>>Figured it would be a good place to use a thread. I wish. I used the Win32
>>>calls and that's the place I am staying for now.
>>>
>>>"Tom Walker" <nobody@example.com> wrote in message
>>>news:uw7TmBRdIHA.4728@TK2MSFTNGP03.phx.gbl...
>>>> "Roger Rabbit" <roger@rabbit.com> wrote in message
>>>> news:7E2C595C-E864-44BE-8330-05525CC33414@microsoft.com...
>>>>> Found this from MSDN->codeguru, can't seem to figure out the 
>>>>> problem....
>>>>
>>>> What is the problem?
>> Joseph M. Newcomer [MVP]
>> email: newcomer@flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm 
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15975)
2/22/2008 6:52:25 PM
Eventually the paint routine will become complicated. The idea I have is to 
use a flag in the thread to be checked and if its an abort flag then the 
draw thread can bail.

Putting the about box on a thread comes from the idea of using a dialog box 
to display progress from say a computationally demanding process that is 
running in the main thread or threads.

I posted a simple routine to better learn the calls needed rather than post 
200,000 lines of code to sift through.

While sifting through MSDN I found a reference for an pfnThreadProc that's 
used to pass the parameter to the child process such as the window handle in 
the example I posted. So I will have to use that vehicle to pass my 
parameter(s) to AfxBeginThread to launch a child process.

Once I have the modules I need built, then I can reuse them in a more 
practical project than the trivial code I posted. The problem is that the 
standard C++ libraries are not thread aware.

I already have a working mutex class so dealing with the need to lock a 
thread to avoid problems is already available.

I am also working on some ideas of implementing a singleton class but this 
is not as easy to do in a threaded environment.

"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
news:p56ur3h2lub440e1d9q287e9taen25l0fe@4ax.com...
> Well, unless you have an *amazingly* complex picture to draw, this is 
> probably a bad place
> to use a thread.
>
> Playing with thread priorities is a guaranteed way to get into trouble 
> nearly all the
> time; it makes sense in some very restricted contexts, but you should make 
> sure you are on
> a multiprocessor before trying to play games with thread priority.
>
> The paint routine is a poor choice for learning threading.
>
> You should not bring up user-visible objects in a secondary thread. 
> Putting the About box
> in a separate thread would be a very poor strategy for program 
> development.
>
> If you are looking for learning exercises for threading, interesting ideas 
> deal with I/O
> devices with unbounded blocking times (for example, serial ports), or 
> situations in which
> concurrency actually buys something (handling many queries at one time, 
> each one of which
> takes a lot of computation).
>
> Painting is a poor choice in general, and take as given that it is a 
> fundamentally Bad
> Idea to put user-visible windows in any but the main GUI thread, and work 
> from there.
>
> Threading is very powerful, and very convenient, but the examples you 
> chose are really
> poor choices for a variety of reasons.
> joe
>
> On Fri, 22 Feb 2008 09:09:32 -0800, "Roger Rabbit" <roger@rabbit.com> 
> wrote:
>
>>OK is this call a better choice?
>>
>> 
>> AfxBeginThread(WorkerThreadProc,NULL,THREAD_PRIORITY_NORMAL,0,0,NULL);
>> MessageBox("Thread Started"); // or just go back to something else
>>
>>where I can change the thread priority to one of the various levels 
>>windows
>>supports.
>>
>>To start with I just wanted to thread the paint routine to lean how to do 
>>it
>>generally. The whole industry is threading everything, I need to be able
>>too.
>>
>>Then after the paint routine, why not thread the about box too. Trivial I
>>agree, but it's the algorithms I am need to learn.
>>
>>"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
>>news:ksjtr35kd8qm0gr6maoa84tmmnv79uf0fv@4ax.com...
>>> IN response to your private email:
>>>
>>> What are you painting that takes so long that a thread is required? 
>>> Note
>>> that there are
>>> valid cases where this can be so, but the example you sent me is trivial
>>> to the point of
>>> irrelevance.
>>>
>>> If you had a very, very complex image to develop, processing it in a
>>> thread can work, but
>>> you need to demonstrate that there is a performance bottleneck related 
>>> to
>>> drawing.
>>>
>>> Also, since the WM_PAINT method comes into the main GUI thread, you have
>>> to somehow route
>>> it to the secondary thread.  This means you cannot declare a PAINTSTRUCT
>>> and use
>>> ::BeginPaint, because that would have to be done in the thread that owns
>>> the window. For
>>> that matter, it is not clear why you are doing this when CPaintDC would 
>>> do
>>> it for you.
>>>
>>> There were three major problems with your example; you said
>>>
>>> void WM_PAINT_PROC(HWND hWnd)
>>>
>>> If this were intended to be a thread function:
>>> 1. The return type is erroneous
>>> 2. The calling convention is erroneous
>>> 3. The parameter is erroneous
>>>
>>> The prototype for a thread function is EXPLICITLY stated in the
>>> documentation as
>>>
>>> DWORD WINAPI ThreadProc(LPVOID)
>>>
>>> and to change any one of these would result in a failure to compile.
>>>
>>> But you should not be using CreateThread, and in using AfxBeginThread, 
>>> the
>>> function
>>> prototype is EXPLICITLY stated in the documentation as
>>>
>>> UINT function(LPVOID)
>>>
>>> and therefore the return type and parameter would be incorrect in your
>>> example, and result
>>> in a failure to compile.
>>>
>>> Note that you have done nothing to demonstrate that you are building a
>>> thread that
>>> processes queued entries for drawing; the cost of creating a thread is 
>>> not
>>> insignificant,
>>> so you cannot be creating the thread each time you need to paint.  The
>>> overhead of thread
>>> creation will probably dominate your drawing time.
>>>
>>> If you had a long, complex painting task, you might consider something
>>> along the lines of
>>>
>>> void CMyThread::OnDrawRequest(WPARAM wParam, LPARAM)
>>>    {
>>>     CPaintDC * dc = (CPaintDC *)wParam;
>>>     while(something to do)
>>>        {
>>>          if(aborting painting)
>>>              break;
>>>          get next item in display list
>>>          draw it
>>>         }
>>>      delete dc;
>>>     }
>>>
>>>
>>> void CMainThread::OnPaint()
>>>    {
>>>     CPaintDC * dc = new CPaintDC;
>>>     drawingthread->PostThreadMessage(UWM_DRAW_REQUEST, (WPARAM)dc);
>>>    }
>>>
>>> But this is based on the premise that redrawing takes a very, very long
>>> time.
>>> joe
>>>
>>> On Thu, 21 Feb 2008 21:40:41 -0800, "Roger Rabbit" <roger@rabbit.com>
>>> wrote:
>>>
>>>>The compiler chokes on the at the mythread declaration, I tried cleaning
>>>>it
>>>>up and reduced the error count 80% and now I am stuck. using VC 08
>>>>express.
>>>>I gave up on the managed attempt, back to regular c++ which at least
>>>>brings
>>>>a large pool of skilled people together.
>>>>
>>>>My goal was an easy to use class for threading. The first place I was
>>>>going
>>>>to use it was in the WM_PAINT_PROC methods I created to draw the screen.
>>>>Figured it would be a good place to use a thread. I wish. I used the 
>>>>Win32
>>>>calls and that's the place I am staying for now.
>>>>
>>>>"Tom Walker" <nobody@example.com> wrote in message
>>>>news:uw7TmBRdIHA.4728@TK2MSFTNGP03.phx.gbl...
>>>>> "Roger Rabbit" <roger@rabbit.com> wrote in message
>>>>> news:7E2C595C-E864-44BE-8330-05525CC33414@microsoft.com...
>>>>>> Found this from MSDN->codeguru, can't seem to figure out the
>>>>>> problem....
>>>>>
>>>>> What is the problem?
>>> Joseph M. Newcomer [MVP]
>>> email: newcomer@flounder.com
>>> Web: http://www.flounder.com
>>> MVP Tips: http://www.flounder.com/mvp_tips.htm
> Joseph M. Newcomer [MVP]
> email: newcomer@flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm 

0
roger8087 (31)
2/25/2008 12:44:36 AM
See below...
On Sun, 24 Feb 2008 16:44:36 -0800, "Roger Rabbit" <roger@rabbit.com> wrote:

>Eventually the paint routine will become complicated. The idea I have is to 
>use a flag in the thread to be checked and if its an abort flag then the 
>draw thread can bail.
****
Define "complicated".  There are lots of ways to optimize drawing that doesn't involve
threading as a solution.  Not that threading is bad as such, but you need to consider that
there are often better alternatives.
****
>
>Putting the about box on a thread comes from the idea of using a dialog box 
>to display progress from say a computationally demanding process that is 
>running in the main thread or threads.
>
>I posted a simple routine to better learn the calls needed rather than post 
>200,000 lines of code to sift through.
****
Learning the calls by choosing bad ideas doesn't help learn the calls.  It merely adds
confusion caused by using bad ideas, such as user-visible objects in threads whose parents
are in a different thread.
****
>
>While sifting through MSDN I found a reference for an pfnThreadProc that's 
>used to pass the parameter to the child process such as the window handle in 
>the example I posted. So I will have to use that vehicle to pass my 
>parameter(s) to AfxBeginThread to launch a child process.
****
Do you mean "worker thread" instead of "child process"?  Yes, the parameter to
AfxBeginThread (I have no idea what a pfnThreadProc is, since you gave no context) is used
to pass parameters to the thread.  The question is, what parameter do youwant to pass? The
window handle is generally a poor choice a lot of the time.  Only in a few limited
contexts does it give any advantage over passing a CWnd*.
****
>
>Once I have the modules I need built, then I can reuse them in a more 
>practical project than the trivial code I posted. The problem is that the 
>standard C++ libraries are not thread aware.
****
I have no idea what you mean by this.  Do you mean std::?  Yes, none of these are
thread-aware, but that's why you have synchronization primitives lie CRITICAL_SECTION.
More importantly, try to avoid *needing* synchronization.  So the question is: why
construct a system in which you need to provide for synchronization?  Why not avoid it
entirely by creating a system that doesn't need synchronization at all?  (See my essay:
The Best Synchronization is No Synchronization)
****
>
>I already have a working mutex class so dealing with the need to lock a 
>thread to avoid problems is already available.
****
OK, is there a justification for using a mutex instead of a CRITICAL_SECTION?  What,
precisely, does this class do that requires a separate class to handle it, as opposed to
just calling EnterCriticalSection? (there *are* correct answers to this question, by the
way).  Generally, synchronization is either so simple you don't need a class, or so
complicated that a class doesn't solve anything.
****
>
>I am also working on some ideas of implementing a singleton class but this 
>is not as easy to do in a threaded environment.
****
Depends on what it is supposed to do.  Note a singleton class should be trivial in a
mulithreaded environment, no harder than a simple variable.
					joe
****
>
>"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
>news:p56ur3h2lub440e1d9q287e9taen25l0fe@4ax.com...
>> Well, unless you have an *amazingly* complex picture to draw, this is 
>> probably a bad place
>> to use a thread.
>>
>> Playing with thread priorities is a guaranteed way to get into trouble 
>> nearly all the
>> time; it makes sense in some very restricted contexts, but you should make 
>> sure you are on
>> a multiprocessor before trying to play games with thread priority.
>>
>> The paint routine is a poor choice for learning threading.
>>
>> You should not bring up user-visible objects in a secondary thread. 
>> Putting the About box
>> in a separate thread would be a very poor strategy for program 
>> development.
>>
>> If you are looking for learning exercises for threading, interesting ideas 
>> deal with I/O
>> devices with unbounded blocking times (for example, serial ports), or 
>> situations in which
>> concurrency actually buys something (handling many queries at one time, 
>> each one of which
>> takes a lot of computation).
>>
>> Painting is a poor choice in general, and take as given that it is a 
>> fundamentally Bad
>> Idea to put user-visible windows in any but the main GUI thread, and work 
>> from there.
>>
>> Threading is very powerful, and very convenient, but the examples you 
>> chose are really
>> poor choices for a variety of reasons.
>> joe
>>
>> On Fri, 22 Feb 2008 09:09:32 -0800, "Roger Rabbit" <roger@rabbit.com> 
>> wrote:
>>
>>>OK is this call a better choice?
>>>
>>> 
>>> AfxBeginThread(WorkerThreadProc,NULL,THREAD_PRIORITY_NORMAL,0,0,NULL);
>>> MessageBox("Thread Started"); // or just go back to something else
>>>
>>>where I can change the thread priority to one of the various levels 
>>>windows
>>>supports.
>>>
>>>To start with I just wanted to thread the paint routine to lean how to do 
>>>it
>>>generally. The whole industry is threading everything, I need to be able
>>>too.
>>>
>>>Then after the paint routine, why not thread the about box too. Trivial I
>>>agree, but it's the algorithms I am need to learn.
>>>
>>>"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
>>>news:ksjtr35kd8qm0gr6maoa84tmmnv79uf0fv@4ax.com...
>>>> IN response to your private email:
>>>>
>>>> What are you painting that takes so long that a thread is required? 
>>>> Note
>>>> that there are
>>>> valid cases where this can be so, but the example you sent me is trivial
>>>> to the point of
>>>> irrelevance.
>>>>
>>>> If you had a very, very complex image to develop, processing it in a
>>>> thread can work, but
>>>> you need to demonstrate that there is a performance bottleneck related 
>>>> to
>>>> drawing.
>>>>
>>>> Also, since the WM_PAINT method comes into the main GUI thread, you have
>>>> to somehow route
>>>> it to the secondary thread.  This means you cannot declare a PAINTSTRUCT
>>>> and use
>>>> ::BeginPaint, because that would have to be done in the thread that owns
>>>> the window. For
>>>> that matter, it is not clear why you are doing this when CPaintDC would 
>>>> do
>>>> it for you.
>>>>
>>>> There were three major problems with your example; you said
>>>>
>>>> void WM_PAINT_PROC(HWND hWnd)
>>>>
>>>> If this were intended to be a thread function:
>>>> 1. The return type is erroneous
>>>> 2. The calling convention is erroneous
>>>> 3. The parameter is erroneous
>>>>
>>>> The prototype for a thread function is EXPLICITLY stated in the
>>>> documentation as
>>>>
>>>> DWORD WINAPI ThreadProc(LPVOID)
>>>>
>>>> and to change any one of these would result in a failure to compile.
>>>>
>>>> But you should not be using CreateThread, and in using AfxBeginThread, 
>>>> the
>>>> function
>>>> prototype is EXPLICITLY stated in the documentation as
>>>>
>>>> UINT function(LPVOID)
>>>>
>>>> and therefore the return type and parameter would be incorrect in your
>>>> example, and result
>>>> in a failure to compile.
>>>>
>>>> Note that you have done nothing to demonstrate that you are building a
>>>> thread that
>>>> processes queued entries for drawing; the cost of creating a thread is 
>>>> not
>>>> insignificant,
>>>> so you cannot be creating the thread each time you need to paint.  The
>>>> overhead of thread
>>>> creation will probably dominate your drawing time.
>>>>
>>>> If you had a long, complex painting task, you might consider something
>>>> along the lines of
>>>>
>>>> void CMyThread::OnDrawRequest(WPARAM wParam, LPARAM)
>>>>    {
>>>>     CPaintDC * dc = (CPaintDC *)wParam;
>>>>     while(something to do)
>>>>        {
>>>>          if(aborting painting)
>>>>              break;
>>>>          get next item in display list
>>>>          draw it
>>>>         }
>>>>      delete dc;
>>>>     }
>>>>
>>>>
>>>> void CMainThread::OnPaint()
>>>>    {
>>>>     CPaintDC * dc = new CPaintDC;
>>>>     drawingthread->PostThreadMessage(UWM_DRAW_REQUEST, (WPARAM)dc);
>>>>    }
>>>>
>>>> But this is based on the premise that redrawing takes a very, very long
>>>> time.
>>>> joe
>>>>
>>>> On Thu, 21 Feb 2008 21:40:41 -0800, "Roger Rabbit" <roger@rabbit.com>
>>>> wrote:
>>>>
>>>>>The compiler chokes on the at the mythread declaration, I tried cleaning
>>>>>it
>>>>>up and reduced the error count 80% and now I am stuck. using VC 08
>>>>>express.
>>>>>I gave up on the managed attempt, back to regular c++ which at least
>>>>>brings
>>>>>a large pool of skilled people together.
>>>>>
>>>>>My goal was an easy to use class for threading. The first place I was
>>>>>going
>>>>>to use it was in the WM_PAINT_PROC methods I created to draw the screen.
>>>>>Figured it would be a good place to use a thread. I wish. I used the 
>>>>>Win32
>>>>>calls and that's the place I am staying for now.
>>>>>
>>>>>"Tom Walker" <nobody@example.com> wrote in message
>>>>>news:uw7TmBRdIHA.4728@TK2MSFTNGP03.phx.gbl...
>>>>>> "Roger Rabbit" <roger@rabbit.com> wrote in message
>>>>>> news:7E2C595C-E864-44BE-8330-05525CC33414@microsoft.com...
>>>>>>> Found this from MSDN->codeguru, can't seem to figure out the
>>>>>>> problem....
>>>>>>
>>>>>> What is the problem?
>>>> Joseph M. Newcomer [MVP]
>>>> email: newcomer@flounder.com
>>>> Web: http://www.flounder.com
>>>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>> Joseph M. Newcomer [MVP]
>> email: newcomer@flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm 
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15975)
3/1/2008 5:04:17 AM
Reply:

Similar Artilces:

Date Problem !!
hi there i have a big problem with the dates. i enter 09/10/2005 in a cell and it changes to 10/09/2005 !! big problem. it shows 10/09/2005 in the cell but 09/10/2005 in the formula bar !! 2 different dates very confusing is there a way of telling it to use just one kind ??? thanks -- cassy01 ------------------------------------------------------------------------ cassy01's Profile: http://www.excelforum.com/member.php?action=getinfo&userid=780 View this thread: http://www.excelforum.com/showthread.php?threadid=473175 It's the same date, it's just formatted differently o...

Camera Problem
When my mate and I have video call , I can see both my and his picture but he can only see me, own picture missing, if he uses tools, video audio set up he can see himself,, also he had vidio call to family in Australia and that was fine we are both using 2009 14.0.8089s please ...

Problem with Outlook reminders
Whenever I open the outlook (2007), an error message appears which reads: "There was a problem reading one or more reminders. Some reminders may not appear." I ran outlook /cleanreminders at RUN, it opened Outlook but the error message still appeears. How can I fix this problem? OS is windows 7. Jorge Does this happen even if you start Outlook in Safe Mode? (hold down CTRL while you click the icon) See if this helps: http://www.officeforlawyers.com/outlook/tsol.html#safe -- -Ben- Ben M. Schorr, MVP Roland Schorr & Tower http://www.rolandschorr....

Office:mac 2004 installation problem
Hi, I'm wondering if anyone out there can help me... Way back in March I bought a new MacBook, and with it a copy of Office:mac 2004 student & teacher edition. I installed my copy of Office straight away, but didn't realise I needed to uninstall the Trial edition first. Every time I opened anything in Office, both the REAL and TRIAL editions started up - which is obviously quite annoying - so I tried to uninstall the trial. However, the REAL Office then stopped working. Getting a bit fed up, I tried to completely remove all traces of Office and start again. However, when I tr...

Problem with XmlDocument.Load method.
I get an unhandled exception, when I try to execute XmlDocument.Load(...) in my C# Windows application: -------------------------------------------- "Common Language Runtime Debugging Services" Process id... thread id... Click OK to terminate ... Click Cancel to Debug ... -------------------------------------------- Running environment: Windows 2000 Terminal Server, .NET Framework 1.1 with all latest service packs. But strangest thing is - if I run the same programm as an administrator,everything runs well, but if user is power user or User - I get this exception. Even more - I c...

Data Validation problem #5
hi I think that is a different solution entirely - in that example yo gave me it is a simple case of choosing one list and that then sets th range for list 2, however the second set of lists are all individual my requirement is that the validation picks the required items out o just ONE list, whereas in the example you needed to maintain individua lists each of which was dependant on the first selection -- moosife ----------------------------------------------------------------------- moosifer's Profile: http://www.excelforum.com/member.php?action=getinfo&userid=1590 View this threa...

WindowProc: combobox messages problem
In my CControlBar I have overridden the virtual WindowProc. The combobox on the controlbar displays correct and behaves well in runtime. Now, I spent a couple of hours trying to get some messages that I need, using WindowProc. This is needed because CControlBar will pass everything on to the controlbar owner, and that's not what I want. WindowProc is my way to intercept those messages. I already found out that the messages are, ehm, weird: their numbers do not match on related defines in winuser.h. To give an example: WM_COMMAND, 0x0003 functions as a WM_SETFOCUS. But WM_SETFOCUS is def...

outlook contact list problem
Hello, I've been using Outlook for quite some time and it worked fine. My set-up: At work an english Outlook 2002 At home a german Outlook 2000 To sync I use an IPAQ PPC with Active Sync 3.7 I've now installed bluetooth support and sync even with my SE mobile phone with XTND Before the contact list was on both computers shown as "first last" i.e. Tom Smith, but now suddenly it shows as "Smith, Tom" I checked the settings on both outlooks and it says: "first last" both in - Tools>Options>Contact options> - Tools > E-mail accounts &g...

Format Painter button problem
When I wish to format several cells the same I double click the format painter and I am able to format each cell without reclicking the button. I have just upgraded to Excel 2003 and now I can only do that on a worksheet that hasn't any VBA code attached. Is this a bug? I know other people on Mr Excel are having the same problem and no one seems to have an answer. Thanks for any response or help you may give me. Skip Depends upon the VBA code attached, I would imagine. If you have worksheet event code that formatted cells, this formatting would overwrite what you painted with the...

Strange Exchange 2003 Pop Problem
If anyone may be able to shed some light on this strange happening I would really appreciate it. I have Exchange Server 2003 running, all of my users can check their email using Outlook/Popping just fine. They also can all go to OWA and check their email fine. I have one user that can use OWA to check her mail, it takes her password, lets her in but if she tries to use Outlook on her desktop it keeps popping up a password error. No matter which station I am at, I can not check email with this account other than using OWA with a web browser. Nothing was changed on the server, I have reset the...

ArrayList memory problem
Hi everyone, I've got the following problem: In my application I make use of two ArrayList objects like this: Public Sub Main() LoadData() End Sub Public Function LoadData() Dim list1 as new ArrayList() [...Fill the arraylist...] AnalyzeData(list1) End Function Public Function AnalyzeData(list1 as ArrayList) Dim list2 as new ArrayList list2 = list1 [...do stuff...] list2.Clear() End Function Now, this code creates a major memory leak....calling GC.Collect() etc. won't help. Can anyone tell me what happens, when I call list2 = list1 - is the whole list co...

Problem when opening Excel 2003 file
How come when I open a file in Excel nothing appears? Yet the same file will open correctly on other peoples computers. Hi try the following: goto 'Tools-Options-General " and uncheck "Ignore other Applications" Exit Excel and try again If this doesn't work try to re-register Excel 1. Close Excel first and 2. On the Windows Taskbar 2.1 Start>Run "excel.exe /unregserver"(no quotes)>OK. 2.2 Start>Run "excel.exe /regserver"(no quotes)>OK. -- Regards Frank Kabel Frankfurt, Germany Bruce Weinstein wrote: > How come when I open a file...

CRM Outlook Client Addin Problem
We have our users installed with the CRM Outlook client. They are running Outlook XP with 256MB ram. In general, they were normally. However, when our users select multiple mail in the Outlook, the client hang up for minutes. Does anybody know the cause and solutions? Hi Gordon, there are several possible causes: 1. Which CRM client are you trying to use: Microsoft CRM Desktop Client for Office Outlook, or Microsoft CRM Laptop Client for Office Outlook? 2. What operating system are the PCs running: Windows 2000 SP2 or Windows XP SP1 or Windows XP SP2? 3. Which service pack of Micro...

Strange problem with some contact names / email senders
Hello! I have a strange Outlook problem which is really annyoing me at the moment! I added someone to my contacts but whenever i reply to their email they're name isn't automatically filled in as it does with other people's email. Also, if i Create a New email message, it never auto-completes their name. (ie if info@babylon-webmaster.fsnet.co.uk is in my contacts under 'Babylon', sends me an email and i reply to it "To: " reads "Babylon <info@babylon- webmaster.fsnet.co.uk>", but for this contact "To:" only ever displays their ...

PivotItem Problem !
Hello, Here is my problem : My macro get data from a dynamic table . For each PivotItems in PivotFields("color"), i get the number or sum in the data range. Everything works well the first time but not after. If a data of one pivotItem is empty, the PivotItem is still on the PivotItemS list on the Table. So my loop "For each" return Error when i use the PivotItem LabelRange function , because there is no column (for ex) for that PivotItem. Is there a way to have only real value one that PivotItems. I try the command PivotCache.Refresh but still the same error. Did i ...

Inbox display problem
My 4 year old got on my computer and now my email is only showing the received column. I would like to have the From and Subject put back in there. Don't know and can't figure out how he did it. Anyone? Frank Frank <anonymous@discussions.microsoft.com> wrote: > My 4 year old got on my computer and now my email is only > showing the received column. I would like to have the > From and Subject put back in there. Don't know and can't > figure out how he did it. Anyone? In addition to what Milly said, you can also reset the current view to its defaul...

Problem with Addresses
I have to input an entire phone book of addresses. I have since manually typed 1175 but this is extremely time consuming and there is no end in site. Luckily, the phone book is posted on a website so I can cut and paste the entires However the entries appear on the website like this: Albis Turlington Architects, LLC Phone: 203-772-1212 175 Orange Street Fax: 203-773-1212 New Haven, CT 06510 when pasted into excel they appear in the same manner, each line in a different cell, phone and fax are in their own cells as well. The formatting ...

Outlook 2003 Problem #4
Hi folks, since I have got Outlook 2003 running, I have got the following problem: I use tow write e-mails offline, and then connect to the internet, and send it all at once. This worked always fine with OE, the written mails I sent away offline were copied into the send folder, and were sent away straght after I connected to the internet. Now I observer the followinf with Outlook 2003: Outlook continues to try to send the e-mail permanently, even if I check the correct checkbox for not participating on send offline. I tried to switch off everything I found, to prevent Outlook to permanently...

Query by Form Problem 06-19-07
I'm using QBF with about six different combo boxes using: [forms]! [formmain]! [combo1] or [forms]![formmain1]![combo1] -like in a VBA book. This is so users can select criteria on a form with the combo boxes, and when they are done, they hit the search button, and it opens up another form based on the query just performed by the combo selection. This worked for about three combo boxes, but when I added another one, it freezes up and opens up a blank page. It's supposed to open the new form based on the query. Is there a better way to do this? I've looked exhaustive...

Problem using Microsoft Web Browser control
I am trying to access the Custom properties of a Web Browser ActiveX control on a form and I keep getting a message telling me that "The Operation on the Microsoft Web Browser object failed. The OLE server may not be registered. To register the OLE server, reinstall it." I searched TechNet and MSDN and could not resolve this. I reinstalled Access 2003 (I have 2003 and 2007 installed on my workstation, XP Pro) and still no resolution. Has anyone else seen this and if so, can you tell me how to resolve this? Jim Does anyone know the name of the file the message...

Outlook client and a kerberos problem
I install the outlook client and it did not show me any problem but when I open outlook and try to open CRM tap, it shows me an error messages (with no revelevant information - an error ocurred loading Microsoft CRM functionality). At the application log I can see several errors - from two different origins: Origin : MSCRMAddressBook Origin : MSCRMAddIn And at the system log, I see the following error. The kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/crmserver."our domain". This indicates that the password used to encrypt the kerberos service t...

terrible problem
I would like to know if this is possible: I have two workbooks.. one from this fiscal year and one from last each has 5 reports each of them with 12 months. Currently every month, I pull up last years report and add in the month I am in from last year.. ex: we are in dec of FY 06, so I would go to dec FY 05 and add up sept, oct, nov and dec to get my total. I need to just add a month from the previous year each month. Is there a formula that could do that each month that would just do it when I opened the workbook, if the month had changed?? -- imjustme ---------------------------------...

Passing data to DLL problem
Hi, my application uses a callback function in a dll. This function must notify the main application when it is called, through a SendMessage api call. So i've created a global variable in the dll, named parent: HWND parent; LRESULT CALLBACK MyFunction(...........) { ......................... SendMessage(parent, ....................); } in the main application i set the dll variable: HWND * wnd; wnd = (HWND *) GetProcAddress(hinstDLL, "parent"); *wnd = hWnd; this works fine if i use the parent variable it in a normal dll function, but in the callback MyFunction parent resu...

Money is Having PASSWORD Problems.
Several Money users have not been able to access they Money data since early this week. Microsoft is working on a solution, They will post here when they have it! Thanks No WAY, really? >-----Original Message----- >Several Money users have not been able to access they >Money data since early this week. Microsoft is working on >a solution, They will post here when they have it! > >Thanks >. > ...

custom border problem #3
In Publisher 2007 when I try to create a custom border using a wmf/bmp/gif clipart of 5 to 10 kb size I get the following Alert Message: "This picture is too complex to be made into a border". How can I get around this problem as I have tried over a 100 pieces of clipart which Publisher rejects as too complex. What is an acceptable piece of clipart to Publisher? Surely there must be some simple solution to this. Can anyone help? "Broadford1" <jbane.ennis@eircom.net> wrote in message news:eJZabYejIHA.4064@TK2MSFTNGP06.phx.gbl... > In Publisher 2007 when I ...