Member Avatar for docdj

I have an MFC dialog app with several Text controls. All but controls get filled in with UpdateData at dialog initialization via calls like: DDX_Control(pDX, IDC_MY_STATIC, MyText ); . Next, the user checkmarks a checkbox and the ON_ function for the checkbox gets control, running several functions. One of those functions has a loop that invokes MyText.SetWindowText(somestring) followed by multiple sequential calls to CreateProcess each followed by a WaitForSingleProcess. MyText is a CStatic field attached to the control. Here is the problem: I get the output of the first and last SetWindowText calls, but nothing in between. The created processes take about 2 minutes to run, so there should be sufficient time to see the text in my dialog window.

  • 2 Contributors
  • 3 Replies
  • 81 Views
  • 2 Days Discussion Span
  • Latest Post Latest Post by rproffitt

Dani AI

Generated

Short version for : your dialog is likely not repainting between those SetWindowText calls because the UI thread is blocked while you launch and wait for the child processes. SetWindowText updates the control text, but the actual paint happens when the message loop processes WM_PAINT. If you block the thread with synchronous waits, those intermediate paints never run, so you only see the first (before heavy work) and the final update (after the loop). See the Win32 notes on SetWindowText and how painting is driven by the message loop: SetWindowText (Win32) and UpdateWindow.

Practical options (pick one):

  • Minimal change: force an immediate paint after each text change (call the equivalent of UpdateWindow / RedrawWindow) or pump messages while waiting so WM_PAINT runs. MsgWaitForMultipleObjects is the API that lets you wait for process handles while still processing window messages; use it carefully to avoid reentrancy: MsgWaitForMultipleObjects.

  • Better: do not block the UI thread at all. Run the CreateProcess/Wait loop on a worker thread (for MFC, use AfxBeginThread or std::thread) and post a message to the dialog to update the static text. That keeps the UI responsive and avoids tricky reentrancy issues: .

was right to suggest the DoEvents idea — the MFC/C++ equivalent is message pumping — but the cleanest, safest fix is background work + posted UI updates.

Recommended Answers

All 3 Replies

Member Avatar for rproffitt

The issue is one I've seen over and over on MFC and other apps. There are many priors so look at a few more to see if you can find one you feel applies. For my app I had to add a doevents() call to let Windows process the update.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.