f



CEdit sometimes won't accept text

Hi,
    I have a CFormView SDI application.  The form has, amongst
other things, a CButton and an object of type CConsole subclassed
from CRichEdit2.  When the user clicks on the button, I save
a pointer to the CConsole object (as CConsole *) in a static
variable and then create a worker thread.  The 1st thing the
worker thread did was to append some text to the CConsole object
by sending a message thru the pointer, ie


static CConsole *  spzConsole;

UINT WorkerThread(..)
{
   spzConsole->Printf("Querying Device\n");

   ...
}

   This worked 99.999% of the time.  However, one time on an
XP machine, after I messed around with the F1 help and About
application menu items, I notices that the 1st Printf issued
in the thread did not showed up in the text box.  Later
Printfs issued from the same thread did get displayed.  I clicked
the buttons many times afterwards and the same behavior was
observed everytime.  I then quit the application and relaunch
the application and everytime was ok.  I haven't been able to
see this problem since.

Question is
   1. Is it correct to issue messages to a CRichEdit
      control (or any control for that matter) using a
      pointer.  If not, what is the correct way?
   2. Assuming #1 is correct, why then was the 1st
      Printf not get displayed?

Thanks for all your help..

Andy


0
Andy
6/3/2005 11:38:23 PM
comp.windows.tools.mfc 1371 articles. 0 followers. Post Follow

3 Replies
144 Views

Similar Articles

[PageSpeed] 48

Hi,
   I guess then using PostMessage(..) with a dynamically allocated CString 
and delete
at the receiving end is the way to go?  Regarding PostMessage(...), is 
WM_APP + 1 safe
to use?  I'm also considering using shared memory using CCricitcalSection 
for protection,
but I don't know if I'm using it correctly.  I'm thinking of

CCriticalSection   gzCritical;

void ThreadOneFn(void)
{
    CSingleLock   cs(&gzCritical);

    if (cs.Lock())
    {
         UseSharedData();
     }
}

void ThreadTwoFn(void)
{
    CSingleLock   cs(&gzCritical);

    if (cs.Lock())
    {
         AddSharedData();
     }
}

    Am I using it correctly?  Also, is CCriticalSection Win95 and Win98 
compatible?

Thanks
Andy

Thanks

"Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message 
news:IfOdnSu0CcgrsTzfRVn-uw@comcast.com...
> Andy Chang wrote:
>> Question is
>>    1. Is it correct to issue messages to a CRichEdit
>>       control (or any control for that matter) using a
>>       pointer.  If not, what is the correct way?
>>    2. Assuming #1 is correct, why then was the 1st
>>       Printf not get displayed?
>>
>> Thanks for all your help..
>>
>> Andy
>
> It has nothing to do with using a pointer.  It has everything to do with 
> accessing a control from another thread.  Don't do that.  The control is 
> part of the thread where it was created.  The control only processes 
> messages in the thread where it was created.  The MFC documentation says 
> don't do that.  With some calls it works sometimes.
>
> -- 
> Scott McPhillips [VC++ MVP]
> 


0
Andy
6/4/2005 4:53:49 AM
Andy Chang wrote:
> Question is
>    1. Is it correct to issue messages to a CRichEdit
>       control (or any control for that matter) using a
>       pointer.  If not, what is the correct way?
>    2. Assuming #1 is correct, why then was the 1st
>       Printf not get displayed?
> 
> Thanks for all your help..
> 
> Andy

It has nothing to do with using a pointer.  It has everything to do with 
accessing a control from another thread.  Don't do that.  The control is 
part of the thread where it was created.  The control only processes 
messages in the thread where it was created.  The MFC documentation says 
don't do that.  With some calls it works sometimes.

-- 
Scott McPhillips [VC++ MVP]

0
Scott
6/4/2005 5:23:05 AM
Andy Chang wrote:
> Hi,
>    I guess then using PostMessage(..) with a dynamically allocated CString 
> and delete
> at the receiving end is the way to go?  Regarding PostMessage(...), is 
> WM_APP + 1 safe
> to use?  

Yes, Yes.  You've got the right approach here.

Also, your critical section code seems OK, but I have no experience with 
those, preferring the Win32 sync objects myself.  Both Win32 and MFC 
sync objects are compatible all the way back to Win 95.

-- 
Scott McPhillips [VC++ MVP]

0
Scott
6/4/2005 2:40:26 PM
Reply: