socketconnection-thread issue
loukia
im using a socketconnection component to connect to another pc.when the
address that im entering is
wrong the program freezes for a specific timeout (something like not
responding) because it waits
i would like to ask something about this:
a)how can i change the timeout period ,to make it smaller?it waits far too
long
b)how can i make it so that the program doesnt freeze?put it in a thread?
can you please help me with the code?(SocketConnection1->Active=true; is the
code)
this problem im experiencing in many other applications also,when i put a
big loop for
example and the computer makes long calculations the program freezes.
c)i have one simple line of code before the previous:
Label1->Caption="attempting connection:"
SocketConnection1->Active=true;
but sometimes(maybe most times) the label doesnt change it caption and the
program
appear to move to the next line and freezes until it finishes.of course when
the active true finishes
the label is show but why doesnt the program execute each line and then move
to the next one?
is there a way to avoid this?maybe use something like sleep()?
i would appreciate any help on these questions.thank you very much for your
time
loukia
ps.i would like to apologize if i originally placed this in the wrong
newsgroup,thank you
Remy Lebeau (TeamB)
"loukia" <louk...@hotmail.com> wrote in message
news:45a47b6d$1...@newsgroups.borland.com...
> im using a socketconnection component
Which specific component are you using?
> when the address that im entering is wrong the program freezes for
> a specific timeout (something like not responding) because it waits
As it should be. It is trying to figure out whether the address is
really valid or not. That can be a lengthy operation.
> how can i change the timeout period ,to make it smaller?
You can't.
> it waits far too long
Then only way is to implement your own timeout mechanism that closes
the socket when the timeout elapses.
> how can i make it so that the program doesnt freeze?put it in a
> thread?
Yes.
> this problem im experiencing in many other applications also,when i
> put a big loop for example and the computer makes long calculations
> the program freezes.
That is because you are trying to do everything inside of the main
thread, and thus you are not allowing the main thread to process new
messages in a timely fashion. That is exactly the reason why lengthy
operations do not belong in the main thread to begin with. Use
threads for lengthy operations that should not block the UI.
> i have one simple line of code before the previous:
> Label1->Caption="attempting connection:"
> SocketConnection1->Active=true;
> but sometimes(maybe most times) the label doesnt change it caption
Again, you are not allowing the main thread to process the messages
needed to update the TLabel. As soon as you set the Caption, you are
then entering into a blocking operation immediately. If you must do
that, then you have to call either the TLabel::Update() method or the
TApplication::ProcessMessages() method before activating the socket.
> the program appear to move to the next line
Which it does. UI updates are usually asynchronous. They do not
occur right away, unless you explicitally tell them to.
> and freezes until it finishes.
Because you are blocking the handling of new messages.
> of course when the active true finishes the label is show
Because you are allowing the main thread to return back to the message
queue to handle pending messages.
> why doesnt the program execute each line and then move to
> the next one?
It does. What you are not taking into account is that many
operations, especially UI related ones, do not actually perform their
work right away. They post messages to the queue and then move on,
and then the queue will handle the real work later on when the
messages are processed. That is why you should never block the main
thread for lengthy periods of time. That is why the program appears
to freeze or act sluggish.
> is there a way to avoid this?maybe use something like sleep()?
Sleep() is not the answer. Using worker threads for lengthy
synchronous operations is the answer.
Gambit