Update labels from another thread and context switching

[Mike Doty]

DDT dialog has a label for each thread to show BytesSent progress
Each thread uses CONTROL SET TEXT ghDlg, gControlID(x), BytesSent$
Should only thread running the dialog update the DDT dialog?
Is this causing unnecessary context switching?

http://en.wikipedia.org/wiki/Context_switch

[Michael Mattias]

Updating a control's text will always be done from the context of the thread which owns the window. If that requires a context switch, then Windows does that.

You can cut down on this somewhat by instead of doing a direct call (SetWindowText) (and I thing that's probably what CONTROL SET TEXT does, but since that is proprietary I don't really know) you POST a message to the control of interest (eg WM_SETTEXT) from the calling routine.

Of course, now all such messages get processed when Windows is good and ready to do so, and since multiple such messages may become queued, managing the data (lparam) in a multi-threaded environment may get a tad tricky.

(I'd probably go with a private message... allocating the memory for the text before posting, and deallocating when received)

MCM

[Mike Doty]

Thanks, Michael.

[Roger Garstang]

You need to tell the .NET folks that. I argued forever with a guy from Microsoft that was defending how .NET requires special processing/pages of code just to update a GUI element from a thread. He kept telling me it was dangerous the way PB allows it and it crashes apps. I showed him all my apps that were 1/10th the size of his all working without issue for years.