If you're doing anything time-consumig (like reading data from internet socket) and you want your program to respond to user actions (to Windows / XWindows / any-other-event-driven-environment events), to repaint its windows etc. you have to merge event loop with your data-reading code.
Something like that:
procedure Read_Data_And_Process_Some_Events;
begin
while (not end of data stream) do
begin
read some data
process some events
end;
end;
If you're reading from a file, "read some data" can be something like "read next 1000 bytes from a stream". BUT if you're reading from an internet socket you don't know how long it will take to get "next 1000 bytes" so you should rather limit your reading code by time. Something like
time:=Now;
while (Now-time < 5 seconds) do
begin
peek if there are some data in a stream, if there are - read them
end;
However, that kind of loop is called busy-waiting because if the stream has no more data yet, your program will use a lot of processor time just for peeking. It can be solved by doing Sleep(<for some small amount of time>) after every unsuccesful peek (that's an easy but poor solution) or by doing time-limited waiting for data using OS functions, like select() on sockets (and that's a corect solution).
"process some events" under WinAPI should be something like
if PeekMessage(msg, 0, 0, 0, PM_REMOVE) then
begin
if msg.message=WM_QUIT then break;
TranslateMessage(msg);
DispatchMessage(msg);
end;
If you want only to repaint your windows you can ignore all events except WM_PAINT. In general, you should disable some menus/buttons etc. before calling Read_Data_And_Process_Some_Events. This should make things easier, and it will prevent Read_Data_And_Process_Some_Events from being invoked recursively.
Hope this helps,
Michalis Kamburelis
