Prevent GUI from freezing when loading data into table

[softengr]

I am currently receiving messages over a TCP/IP connection.  Information from these messages is extracted and displayed in a table as they are received.  Many messages are received over a short period of time, and a lot of data is added to the table.  When this occurs, the GUI freezes and the user cannot press the Cancel button until all of the data is inserted into the table.  How could I prevent this freeze from occurring?

I researched this forum and found some tips, but they did not help.  I used SetCtrlAttribute instead of SetCtrlVal when updating the table.  Using SetCtrlAttribute to enter table information slightly reduced the freeze since the table is only redrawn after all information is entered into the table.

[jr_2005]

You probably need to break up the reception of your TCP data into smaller pieces. If your TCP callback function reads all the TCP data, if there is a lot of data it could hog the system and prevent the GUI management from occurring. Just read a reasonable quantity of data and then exit the callback early. After servicing any other outstanding system events the TCP callback will automatically be re-entered to handle more of the data still queued up in the TCP stacks.

JR

[softengr]

That is how it is currently implemented.  My TCP routine detects that the message has been received, and stores it in a temporary data structure.  Then a function (outside of the TCP/IP callback) is called to extract the data from the temporary data structure and place it into the table.

[softengr]

jr_2005, you were right.

After further investigation, I discovered that the TCP event is causing the delay.  When many messages are received in a short amount of time, the GUI freezes.  How can I prevent this? Can you elaborate on what you mentioned before?  Maybe a little example if possible.

Thank you

Message Edited by softengr on 02-06-2009 09:36 AM

[jr_2005]

Well I would start by looking at the total quantity of data expected, and balance the expected average rate (in bytes/sec) with a reasonable response time at the GUI. (~0.2-0.3 seconds/update?). You can then break down the TCB block read sizes accordingly - but of course if there is simply too much data coming in too quickly, it can be tricky to manage. Its a case of trial and error, really - if your basic callback construction can be made programmable it should be easy to play with the parameters until you get a satisfactory solution.

I will not be able to respond to any more forum questions for a while - going on holiday now!

Good luck.

JR

[softengr]

How about creating a separate thread for the TCP Callback? Would that work? This way the GUI updates can still process when the TCP Callback function is active.

[softengr · Accepted solution]

Issue solved:  I created and ran the TCP client in a separate thread from the user interface