Click here to Skip to main content
15,943,477 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hi, dear everyone, When I use CEdit to receive data from serial whose baudrate is 115200bps, when newline comes, i set the CEdit new content, BUT the problem is that the EDIT control shakes and bliks. please, How can I make it normally show the received data?

my code which is used to update CEdit control follows:

int nLength = m_EditSerialRcv.SendMessage(WM_GETTEXTLENGTH);
 if (nLength > 10240)
    nLength = 0;
m_EditSerialRcv.SetSel(nLength, nLength);

Edited by Aescleal (16/04/2012)

(removed solution2 as it was a comment from the questioner, not a solution)

Additional Info: The program is really small, the questioner doesn't (understandably) want the pain of implementing a new control.
Updated 21-Mar-16 20:41pm
Nelek 14-Apr-12 13:20pm    
Where are you calling this code?

It looks like your problem is that you're stuffing text into the control faster than it can manage to display it properly. A high baud serial port is going to want to stuff 1,000 characters a second into the control which is a fair amount for it to cope with. It's really only meant for coping with text entry at something around a human's typing speed.

To demonstrate that this sort of thing affects other apps start notepad up with a really big file, enough to fill about 3 windows worth and start scrolling down. You'll see the text flickering as you scroll off the bottom of the page. If you're still not convinced select a large chunk of text and paste it repeatedly into the document. That'll probably cause a flicker as well.

Anyway, the point is that you're pasting in large chunks of text at one hell of a rate.

So what can you do about it? My first reaction would be to create a custom control that displays the data. This control would have the following characteristics:

- Don't have scroll bars
- Implement a function (define a message) that scrolls the whole shebang up one line at a time
- Implement another function which displays a line of text at the bottom of the control; actually draw it yourself calling TextOut or DrawText
- Only draw in a fixed pitch font, it makes it easier to calculate how much text can go in a line!

Every time you get enough text to fill a line and only then:

- scroll your text up a line
- draw the new line of received text at the bottom

Don't bother invalidating the window, just scroll and draw. This means you don't need to bother having your control actually remember the text supplied to it and all the memory management headaches that go with it. As you don't remember what text to you've written when you get a WM_PAINT message - just ignore it. This means when you switch away from your app the control will loose any text that gets covered up (or all of it if the app's minimised or covered with a maximised window). However with the speed you're generating data from the serial line the window will soon fill up again anyway. That's unless you've got a far bigger monitor than I've got, in which case I want one too.

The speed ups seem to come from not buffering text in the control and making scrolling and new text display as minimal as possible.

I've used this technique to record debugging information that was going too fast for a console window. The control I wrote was able to keep up with displaying lines of up to 128 characters long and had remarkably little flicker. This is about 1/8 of the speed you'll need the display to move but it's better than I managed with an edit control and I never tested it at higher rates.

Now... what to do if you don't know how to write custom controls? I'd grab two books, both of which are probably out of print:

- Programming Windows (5th Edition) - Charles Petzold
- Programming Windows with MFC (2nd Edition) - Jeff Prosise

While it costs and arm and a leg to buy new copies you can pick used copies of the pair of them for a total of about £40 in the UK, $50 in the US. Sorry I don't know about the rest of the world, but Amazon usually have traders who flog them second hand. They're good references on how to program Windows with and without MFC. If you intend to be a serious windows UI programmer using C++ and MFC they're essential reads in my opinion. And they have the bonus of being heavy enough to use as offensive weapons if they don't do it for you as programming texts.

Anyway, I hope this helps and doesn't depress you too much with the extra work involved. I also hope someone suggests a quicker solution as I'd love to know how to display loads of data quickly in windows without flickering too much!



Edited for Mother Tongue failiure
Share this answer
Nelek 14-Apr-12 16:38pm    
Nice explanation. +5
I asked about the calling of the code because I thought it was being called at each "packet received". I would say a good option to build a input buffer to catch everything before sending to CEdit or something like that, but not sure if transmitted data would allow it
terrychx 16-Apr-12 7:43am    
thanks for what you have suggested. But, I really don't want to carefully to learn the MS MFC, I just use MFC to develop a simple GUI testing tool for my receiver.
Aescleal 16-Apr-12 9:07am    
I can see why if you're just writing a one off program. Have you tried any of Jochen's ideas below, they might help?
Solution 1 by Aescleal is a very good explanation.

If you don't want to create a custom control, it may be possible to reduce the flickering. But it can't be totally avoided using a CEdit control.

You existing code can be tweaked:

  • You may count the used edit size yourself and avoid calling GetLength().
  • Calling LineScroll() is not necessary, because using ReplaceSel() will scroll here.

You may use a text buffer, append new lines to this buffer and use SetWindowText() to pass the complete content to the Edit control. With the small buffer size of 10240, this may result in less flickering.
Share this answer
Aescleal 16-Apr-12 5:28am    
5 from me, hopefully this lot will give the poor soul some other things to try!
terrychx 16-Apr-12 7:42am    
I will try what you suggested, 3QS a lot.
terrychx 16-Apr-12 8:49am    
Now, my code which is used to update the CEdit control when a text line arrives is like this:
if (m_TextLen >= 10*1024)
m_TextLen = cnt;
m_EditSerialRcv.SetSel(0, 0);
m_TextLen += cnt;
m_EditSerialRcv.SetSel(m_TextLen, m_TextLen);

this could not avoid flickering entirely but it is much improvable.
i didn't understand the meaning of updating an edit control in high speed. nobody going to read that in anyway :) ? .. i think you should update that less frequently if possible.
Share this answer
Aescleal 16-Apr-12 5:32am    
That was my first thought as well, but I assume it has some utility even if it was "My useless boss told me to do it..."
jk chan 16-Apr-12 5:45am    
terrychx 16-Apr-12 7:41am    
this is possible that the serial data comes slowly, sometime(per second) about 4096 bytes data arrive from the serial, this will lead to refresh the CEdit control and flick...

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900