I have a lot of control need to refresh the MFC interface, and very frequently, causing the program card, want to use a thread to optimize interface,
As shown in figure 1, it is my part of the interface, figure 2 is a serial port receives the data, the interface of figure 3 is a serial port data parsing, refresh is similar to a figure 3 a function
Void CTestselfDlg: : DlgAutoCheck (BYTE * ReceiveData, bool reset)
I want to use a thread to handle data and interface, but try many way to also have no implementation, online seek advice!!!!!!

CodePudding user response:

First of all, you should be receiving serial data in the thread, do not use the mscomm control, to switch to other serial port, processed need to refresh the thread, the sending messages to the window refresh,
The main window frequent refresh these controls should be no pressure,

CodePudding user response:

reference 1st floor mmcanyu response:

first of all, you should be receiving serial data in the thread, do not use the mscomm control, to switch to other serial port, processed need to refresh the thread, the sending messages to the window refresh,
The main window frequent refresh these controls should be no pressure,

Then I should use which class is better?

CodePudding user response:

CSerialPort CnComm, I personally use has been CnComm,

CodePudding user response:

You can find out where is the bottleneck (not necessarily was set in the interface, more than 100 check box, I don't think to operate there will be a very obvious delay),
You can write a test code, don't get data from ReceiveData, set round all the controls, see how long time;
And then test the actual code, you are a lot of time among, is certainly ReceiveData too slow;
If is truly ReceiveData problem, you can:
A, A single thread based display window, and set up the control state; Another thread just ReceiveData, and PostMessage the received data to the UI thread, it won't break to refresh the UI process;
B, reduce the time overhead of data received, because I rarely use this MSComm so not sure whether to support the following:
1, read a serial port in a non-blocking mode, can also be a serial port complete event associated with IOCP (more complex programming model, after you make asynchronous requests, program may continue to go down, the operating system will inform you finished);
2, can consider to state in the sender combined into a whole block of data, a send and receive a number of sensors,
Serial port operation library recommend http://www.naughter.com/serialport.html