No announcement yet.

Update labels from another thread and context switching

  • Filter
  • Time
  • Show
Clear All
new posts

  • Update labels from another thread and context switching

    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?
    Last edited by Mike Doty; 11 Dec 2008, 10:22 AM.
    The world is full of apathy, but who cares?

  • #2
    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)

    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]


    • #3
      Thanks, Michael.
      The world is full of apathy, but who cares?


      • #4
        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.
        Mobile Solutions
        Sys Analyst and Development