My guess is that with PostMessage your string was going out of scope
before
being used by the window (when message processed). SendMessage() will
cause
the thread to wait until the message is processed and may not be what you
really want. Maybe you could add the string object as a CString to your
thread class then it would always be in scope so long as that object
exists?
You could copy the other string data (from wherever in your thread) to
that
class member (or members if more than on string needed). What I typically
do is create a object for the data I want to pass around and make a new
object in the thread that is deleted after being used in the handler.
That
seems to work pretty well.
Tom
"Torsten Hensel" <Hensz@expires-31-03-2008.news-group.org> wrote in
message
news:1205417580.04@user.newsoffice.de...
Joseph M. Newcomer wrote:
PostMessage is robust, up to the issue of message queue saturation (the
result of sending
thousands of messages per second), and I have a generalization that
works
even in this
situation, although it is probably overkill in yours.
I changed my application that it now uses messages - but SendMessage
instead of PostMessage. With PostMessage I could not send strings (I
received access violations).
But what about closing the application? Currently I'm using
PostMessage(WM_QUIT, ErrorCode, 0); which is quite brute. Before that I
tried EndDialog, but this failed when I used a worker thread.
Best regards,
Torsten
Joseph M. Newcomer [MVP]