[RESOLVED] Dialog : How to update an Edit Box?

VC++6.
I have a simple Dialog app. There is one Edit Box, updated in a function triggered by a Button. In the function, the Edit Box's CString member variable is modified twice, firstly as "a", then with "b". I have added a wait of 1 second between the two settings (to simulate some data collection tasks).
Whether I use
SetDlgItemText(IDC_DATA,m_data);
or
UpdateData(false) or UpdateData(NULL)
in conjunction with, or without
Invalidate();
only the text "b" appears in the Edit Box.
If however I insert
AfxMessageBox("paws");
after UpdateData(false), the text "a" does indeed appear in the Edit Box, and on quitting the AfxMessageBox, the text "b" appears in the Edit Box.
Obviously Winclows needs to perceive some or all of the Dialog Window as needing to be repainted - as evinced by the inclusion of the AfxMessageBox, which forces a repaint, but I cannot find a method which does this seamlessly.

I didn't understand why you need to modify your editbox

Quote:

---

Originally Posted by crasher

...twice, firstly as "a", then with "b"

---

however, the simplest way to implement is, IMHO, would be modifying it from within the OnTimer message handler.

Forget about what are you doing, and tell us what you want to achieve. If you don't append to the edit text, then it's normal that you only see the last updated text.

I have an application which communicates with some measurement hardware, and I want to display the readings from that hardware, which consist of several digits. I do not need a sophisticated display - a humble text box will do nicely. I do not want to scroll the output into a document view. Having tried and failed to get the Edit Box to work in my real app, I created a simple test app which illustrates the problem.

It may be that if your app is cpu bound, Windows just isn't getting a chance to update the edit control. Either include a message pump (PeekMessage followed by DispatchMessage) or call UpdateWindow on your edit control and see if that helps.

1) if you don't need to edit the data, and don't need to be able to copy/paste from the data. Then using a static control is a better solution.

2) You're only seeing the last value because in between value changes no redraw is being forced.
Set the text and then force a redraw by calling UpdateWindow()




It'll work, but it is a "cludge" solution though. The main issue is that your application isn't responsive until you return to the normal message loop.
For a 'quick and dirty' program you only use yourself, it'll probably make do. For a program you intend to publish it's bad practice and you should reorganise to not multiple 'overwriting' updates to the same control within a single messagehandling.

Quote:

---

Originally Posted by crasher

... I do not want to scroll the output into a document view. Having tried and failed to get the Edit Box to work in my real app...

---

Well editbox is not the best choice for logging. Di you consider using List box instead? Have a look at A Logging ListBox Control

Quote:

---

Originally Posted by crasher

I have added a wait of 1 second between the two settings (to simulate some data collection tasks).

---

How are you waiting? If you do it in the main thread, the user interface won't be redrawn until the function exits, because the thread is busy.

The problem you have is that UpdateData, Invalidate, SetDlgItemText, and other similar calls actually perform what they are supposed to do, but the edit control itself does not repaint (with the new text) until the windows messages are processed. While you are in your function (waiting with a sleep or whatever) those windows messages are not processed.

However, you can force the window to repaint by using the UpdateWindow function.

Code:

---

SetDlgItemText (IDC_WHATEVER, _T("Text to be displayed."));
GetDlgItem(IDC_WHATEVER)->UpdateWindow();
// do your other stuff here - the window has already been updated

---

Hope that helps.

Quote:

---

Originally Posted by krmed

The problem you have is that UpdateData, Invalidate, SetDlgItemText, and other similar calls actually perform what they are supposed to do, but the edit control itself does not repaint (with the new text) until the windows messages are processed. While you are in your function (waiting with a sleep or whatever) those windows messages are not processed.

However, you can force the window to repaint by using the UpdateWindow function.

Code:

---

SetDlgItemText (IDC_WHATEVER, _T("Text to be displayed."));
GetDlgItem(IDC_WHATEVER)->UpdateWindow();
// do your other stuff here - the window has already been updated

---

Hope that helps.

---

Didn't I say that already?:confused::wave:

Ya, but sometimes people have to hear it twice (or more).

Most likely the underlying problem is that you are performing the hardware work in the main UI thread. This is causing the UI to not process windows messages quickly enough.

Pull your hardware code into a second thread, and post a message to the UI thread when data has arrived.

See the articles in my signature line for a couple of these multithreading examples.

Thanks GCDEF and krmed, whereby krmed actually went to the trouble of posting how to UpdateWindow(). Actually, UpdateWindow() does nothing disecernible if entered verbatim - presumably it updates something to do with the main window. I had already tried that , before GCDEF suggested it. But without the detail provided by krmed, I wouldn't have got the result I need. Saved me clicking around with multiple threading and phase locked-loops, which are interesting in their own right, but I gotta get ma hardware workin sometime too.
Thanks again!

Quote:

---

Originally Posted by crasher

Thanks GCDEF and krmed, whereby krmed actually went to the trouble of posting how to UpdateWindow(). Actually, UpdateWindow() does nothing disecernible if entered verbatim - presumably it updates something to do with the main window. I had already tried that , before GCDEF suggested it. But without the detail provided by krmed, I wouldn't have got the result I need.

---

To be fair, GCDEF said:

Quote:

---

call UpdateWindow on your edit control

---

I guess he thought that you can figure out how to get a handle to your edit control.

Quote:

---

Originally Posted by crasher

Saved me clicking around with multiple threading and phase locked-loops, which are interesting in their own right, but I gotta get ma hardware workin sometime too.

---

Although it looks like your immediate problem is solved with this UpdateWindow(), I predict that VERY soon you will find another problem with updating, for example, a progress bar or something. That one could also be solved by another strategically placed call to UpdateWindow(), but what would you do when you need to implement a “Cancel” (or “Stop”) button, or some other user control?

There is only one correct way to implement time-consuming processing, as Arjay suggested, - on a separate (from main UI) thread.
You can learn from other people experience, or you can make your own errors and learn that way (I hear you remember those things MUCH better).

Quote:

---

Originally Posted by VladimirF

There is only one correct way to implement time-consuming processing, as Arjay suggested, - on a separate (from main UI) thread.
You can learn from other people experience, or you can make your own errors and learn that way (I hear you remember those things MUCH better).

---

I still prefer message pumps. Easier to set up and less to coordinate.

Quote:

---

Originally Posted by GCDEF

I still prefer message pumps. Easier to set up and less to coordinate.

---

Some feel that way. My experience is this is true for only very simple scenarios. For more complex scenarios (where you would like to control the operation), a proper threaded solution is usually easier to implement and maintain.

In my opinion, if you are trying to retrieve data from some external source (like a device, serial port, or network), you should never put this work inside the main UI thread. The reason being is that the user can interrupt the operation and cause data loss by simply moving the window or the mouse.

Let's have a little fun. Code up a simple app that performs some external data operation that needs to be started, stopped, paused, and restarted. Do it all in the main UI thread and then I'll do it using a secondary thread and we'll compare the two approaches.

Quote:

---

Originally Posted by GCDEF

I still prefer message pumps. Easier to set up and less to coordinate.

---

I think that the message pump is easier only for trivial cases. Otherwise there could be a LOT of things to consider:
- can you interrupt your process often enough to pump messages?
- is a start of modal dialog going to affect your pump?
- do you need to translate accelerators, and are there more than one table?
I could through more things in this mix, but I am sure – you can too.