How to get the text of an "EDIT" control from another thread?

[OReubens]

My program is designed in a way that no deadlock will occur.

If your worker threads SEND messages to your UI thread. There is no way you can guarantee that no deadlock will ever occur and that all those sends will be successful, consistent and not cause crashes.

Like I said before, maybe it works for you... on your PC, today, with your current version of windows, service packs and hardware and drivers.
And some point in the future, You'll get slapped in the face by murphy's law. ANd Murphy being the $*@&# he is, will hit you as hard as he can on the most inconvenient moment in time.

[john_n]

If your worker threads SEND messages to your UI thread. There is no way you can guarantee that no deadlock will ever occur and that all those sends will be successful, consistent and not cause crashes.

Like I said before, maybe it works for you... on your PC, today, with your current version of windows, service packs and hardware and drivers.
And some point in the future, You'll get slapped in the face by murphy's law. ANd Murphy being the $*@&# he is, will hit you as hard as he can on the most inconvenient moment in time.

Even if I decided to block the worker thread, I will not use SendMessage() anymore, I will use PostMessage() to send user-defined messages to the UI thread and then wait on an event that will be signaled from the UI thread when the message is processed.

[OReubens]

Even if I decided to block the worker thread, I will not use SendMessage() anymore, I will use PostMessage() to send user-defined messages to the UI thread and then wait on an event that will be signaled from the UI thread when the message is processed.

Yes, as I said before, this'll work, but it's synchronicity by using a double asynchrone approach. Which makes it a less than ideal solution. There's a few gotcha's with the approach, one of them being. What happens if your UI is in the point of shutting down at the point in time your worker tread sends the message, and your UI never gets back to processing that message...

Real life being the way it is, for a legacy application, it may be your only realistic solution without having to rewrite/rethink the whole UI.
If you're writing a new application... "you are doing it the wrong way", there, you've been warned. What you choose to do with that warning is entirely up to you. If you do decide to go with the double asynchrony anyways... I will reserve the right to tell you "I told you so" at some point in the future. ;-)

[john_n]

Yes, as I said before, this'll work, but it's synchronicity by using a double asynchrone approach. Which makes it a less than ideal solution. There's a few gotcha's with the approach, one of them being. What happens if your UI is in the point of shutting down at the point in time your worker tread sends the message, and your UI never gets back to processing that message...

I didn't quite understand what you mean. Do you mean that when my program is closed, there could be a message to be processed (for example: add "Hello World!" into ListBox1)? If so, then no problem with that because the program is closed, so it's normal that some work that's being done by the program will be halted!

As if you mean that at the time I close the program, and send a message to the worker threads telling them to close themselves and at the same time the worker threads are waiting for the UI thread to process a message they have previously sent, which will cause a deadlock. Then this is how I will solve this problem:
When a worker thread sends a message, it will then wait on two events: one to be signaled when the message is processed, and the other to be signaled when closing the program (to break the "PostMessage() block" if any, and hence no deadlock will occur).

[OReubens]

Yes, that's one solution for one gotcha, there's more, the problem with this type of solution is that
you either don't bother because it's a hack and you know it's got a low chance of failing.
you do bother, and then you get a bunch of code that can easily become quite complex and unmanageable.

For a legacy app. that may be the only viable alternative.

but if you're writing new software, you can do a much better/cleaner approach by doing it right. More often than not, the design/approach changes you need to do to make your UI cleanly support worker threads, end up making both the UI and the worker threads better both from a design POV as well as from a management and performance POV.

[ovidiucucu]

Well, because this is a simplified scenario of why I need to make sure that PostMessage() does not return until I get the UI control content. But my real scenario is many lines of code long that will broke my program if not kept in the worker thread.

Smoking few threads with a flavor of GUI can make you feel great but sooner or later may give nasty and painful headaches.
In case of abuse, of course.

[ later edit ]
Never forget the KISS paradigm!

[ later of later edit ]
PostMessage, according to the documentation, returns immediately no matter what you are smoking.

[john_n]

[ later of later edit ]
PostMessage, according to the documentation, returns immediately no matter what you are smoking.

I meant using PostMessage() + waiting on an Event.