Indy Step by Step - Part3 Building the client(1分)

It's time now to look inside creating TCP/IP clients with Indy. If you have read the first 3 parts of this tutorial, will be really easly to understand how can you build clients.
Building clients is really easy. Just drop an TIdTCPClient component on the form and your client is 80% ready. The second 20% part we will analise in this part.
Remember our server we have studied in the previous part. It's a server that knows just 2 commands. Hello and Add. For this server we will develop a client. Drop 2 buttons on the form and an TIdTcpClient. Also, add a TListbox. In this Listbox we will store the values we want to send to the server with Add comand. You have to set the Port and the Host properies of TIdTcpClient. The Port property is the port of our server(1111). If the server program runs on the same machine, set the Host property to 127.0.0.1 value (the address of localhost). If it not runs on the same machine, set this property with the server's machine IP address (or host name).
First, we will implement the Hello command.do
uble click on the first button and write the following code:
procedure TForm1.Button1Click(Sender:TObject);
begin

with IdTcpClient1do

begin

connect;
Writeln('Hello');
ShowMessage(Readln);
Disconnect;
end;

end;

Now just start the program (and the server) and click on the first button. If all is OK, the result will be a message with "Ok, I have responded" message.
Now, we will implement the second command. As you remember, the Add command is a command with undefined number of parameters. When we use it, we can send to the server any no. of values and the server will return the sum of this values. Let's start:
procedure TForm1.Button2Click(Sender:TObject);
var
command: string;
i:integer;
begin

command:='Add';
for i:=0 to ListBox1.Items.Count -1do

command:=command+' '+ListBox1.Items;

with IdTcpClient1do

begin

connect;
Writeln(command);
ShowMessage(Readln);
Disconnect;
end;

end;

As you can see this command was implemented in the same maneer. The only one difference is the command variable that is "composed" based on items that are in the listbox. Simply. Extreme simply.
At this point, I have to say that when you develop a client for your server application you need more attention. I.E. your client can be inutilisable if you WriteLn when your serverdo
the same WriteLn. You must respect the order of the command thats server has implemented. For example, if on the server side you have something like bellow:
WriteStream (...);
Writeln(...);
ReadStream(...);

your client must strictly respects this order. So, your client application must have implemented something like bellow:
ReadStream(...);
ReadLn;
WriteStram(...);

In other cases your application will not be able to sends or receives data from server.
The next point of our discussion is about clients looking. In programs that intensive exchange big size streams the "no paint sindrom" is observed. Why? Simply. The application stop the paint process because it waits for sending or receiving data. In this case, you have 2 alternatives. First is little hard. You can put the TIdTcpClient component into a separate thread. In this case, your window will function almost normal. The second alternative is to use the TIdAntiFreeze component that is included in the Indy package. You have to put it on the form and your form will look normal. TIdAntiFreeze component has 2 important properties. First is Active property. When this property is set to true, your window will be painted normal. The second property is the ApplicationHasPriority property. It is a boolean property and, as the name suggest, it set the priority between application and indy sockets. If it is set to true, the application has priority and your windows will be paint faster. If it is set to false, the indy connection will have the priority. Related to this component, you have to know that are allowed only one instance of a TIdAntiFreeze component in the application. In fact, the correct is to say that are allowed only one Active instance of it. If you have more than one active instances of this component an error will be raised.
Because I have said about large amount of data exchange, you maybe will think about a method to monitor this process. I.e. you can be interested in monitoring the sending/receiving process with a TProgressBar. The Indy creators has implement all we need. The TIdTcpClient has 3 events defined fordo
ing this:
OnWorkbegin

It is handled every time when a transfer starts. AWorkMode represents the type of transfer. If AWorkMode is wmRead a receive process is to be start, if it is wmWrite a send process is to be start. The AWorkMaxCount is an integer value that represent the size of data that is to be send/receive. Here you can set your progressBar properties (init it) like bellow:
ProgressBar1.Max:=AWorkMaxCount;

OnWork
It is a event that is handeled every time when you transfer something (send or receive). With AWorkCount value, it informs you about the amount of data that was transfered. You can associate to this event a code like:
ProgressBar1.Progress:= AWorkCount;

if you want to monitor your transmission.
OnWorkEnd
It is handeled when the transfer isdo
ne. Here you can reset your progressBar, like bellow:
ProgressBar1.Progress:=0;

And here is our finish with the Indi's TCP IP components. In the next part we will create some "complex" applications, and then
we will study another cool protocol named UDP.