CVI tcp/ip library question

[Vishi Anand]

I am using ConnectToTCPServer function to connect to my TCP server. This
function doesn't take NULL for Callback Function parameter, so I am passing
a valid callback function but nothing inside, as shown below:

static int CVICALLBACK ClientTCPCB(unsigned Handle, int Event, int ErrCode,
void *pCallbackData)
{
switch (Event) {
case TCP_DATAREADY:
break;
case TCP_DISCONNECT:
break;
}

return 0;
}


With this, I see that my GUI seems to hang up as the above callback gets
called every so often as my server keeps sending data, maybe to fast.

So I put ProcessSystemEvents() in the above callback for TCP_DATAREADY case,
now it is running better. Is the right way to do it?

I am thinking of putting this callback
in a separate thread, that should fix
this problem.


vishi

[aperez]

Vishi,

If you are not going to process the events sent by the TCP server, you can eliminate the switch statement altogether and just have a return statement inside the callback. That way you are not spending any time inside the callback (thus eliminating the need to call ProcessSystemEvents), although I'm still puzzled by the hang you mentioned in the GUI.
Why do you need to have a connection to the server open if you are not interested in the data or the status of the connection?

[Vishi Anand]

What I am doing is send some command to the server with TCP_Write and then
do TCP_Read for server's response. I am not waiting for TCP_DATAREADY event
and then do TCP_Read.

I know I should come up with a better way where I use ClientTCPCallBack
function to read data from Server once I get TCP_DATAREADY event.


vishi



"aperez" wrote in message
news:5065000000050000003DCF0000-1042324653000@exchange.ni.com...
> Vishi,
>
> If you are not going to process the events sent by the TCP server, you
> can eliminate the switch statement altogether and just have a return
> statement inside the callback. That way you are not spending any time
> inside the callback (thus eliminating the need to call
> ProcessSystemEvents), although I'm still puzzled by th
e hang you
> mentioned in the GUI.
> Why do you need to have a connection to the server open if you are not
> interested in the data or the status of the connection?