: [twsocket] Messages being sent, but Client app locking up
Hello Clay,
The app became totally unresponsive. As mentioned in an earlier post,
I think, though, I fixed it by calling TWSocket's Close() method.
You you have an OnDataAvailable handler and if yes, do you receive always
all data ?
---
Rgds
Hello Clay,
The app became totally unresponsive. As mentioned in an earlier post, I
think, though, I fixed it by calling TWSocket's Close() method.
You you have an OnDataAvailable handler and if yes, do you receive
always all data ?
---
Rgds, Wilfried [TeamICS]
What exacly mean by 'locks up' ? Is the application not receiving windows
messages anymore (eg mouse clicks and so), or something else ?
The app became totally unresponsive. As mentioned in an earlier post, I
think, though, I fixed it by calling TWSocket's Close() method.
The information
I am successfully sending messages from my Client MIDAS app to my Server
MIDAS app, but then the Client app locks up.
Here is my code:
1) The user (me) presses a button to send a message:
{ This is a test }
procedure TfClientMain.Button1Click(Sender: TObject);
begin
SendMessageToRealTime(1,
Oops, I left out a part:
{ Called by SendMessageToRealTime() }
procedure TfClientMain.ICS_SendString(AMessageToSend: String);
begin
try
ICSSocket_Sending.SendStr(AMessageToSend);
except
on E: Exception do begin
ShowMessage(Format('%s: %s', [E.ClassName, E.Message]));
Adding ICSSocket_Sending.Close as shown below solves the lockup problem:
for i := Pred(slMessagesToSend.Count) downto 0 do
slMessagesToSend.Delete(i);
ICSSocket_Sending.Close; //Voila!
The information transmitted is intended only for the person or entity to
which it is addressed and may
The app. does something like this:
repeat
send something;
wait some ms;
until ende = true;
This is bad design considering you are using an asynchonous component. You must
replace any loop by
a cascade of events. Just like any normal GUI program: you have a running
message pump (you
The app. does something like this:
repeat
send something;
wait some ms;
until ende = true;
This is bad design considering you are using an asynchonous
component. You must replace any loop by
a cascade of events. Just like any normal GUI program: you
have a running message
I know that this is bad design, but that is used only for testing the dll,
nothing more. Later it will be replaced by another dll which
really will be event driven. For simple
test purposes such a complicated event driven app.
would be overkill!
You are loosing your time writing 'test code
Hello Markus,
I know that this is bad design, but that is used only for testing the dll
Later it will be replaced by another dll which really will be event driven
First of all, writing event driven is in fact more simple that
sequentional programming if you are used to do it. Secondly you are
Hello,
does a sending TWSocket need to have its messages processed? If yes how is
this done?
A simple loop directly after sending which calls processmessages of the
socket?
Greetings
Markus Humm
--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Hello Markus,
You can use the messagepump of one of the TWSocket you creeate. Be sure
to set MultiThreaded to True; You have to create all components IN
Execute method of the thrad, assigne all events, and then just call the
messagepump of 1 of the components. Dont forget to destroy all
does a sending TWSocket need to have its messages processed?
Yes, it have to.
If yes how is this done?
A simple loop directly after sending which calls
processmessages of the socket?
Anything that makes messages properly processed is good. But be aware of the
context where it is
called.
Hello Markus,
If you call the message pump, then depending on who called your code,
your function can be re-entered. For example if the caller himself comes
from the messagepump then it can be calling again if message in queue.
Most of the time pumping messages in code is a bad idea and should
You can't call the message pump from anywhere.
Where would it be impossible?
Each time you call the message pump, you trigger message processing. If you
trigger message
processing, you must be prepared to have your event reentered. Basically it is
not a problem but
actually it is since most
03, 2005 5:14 PM
Subject: [twsocket] Messages
Hello,
after sendin I have now (only for test purposes) a 100 ms loop
which calls twsocket's processmessages. The result is, that sending
now works fine again from the test app. and the test app. responds
to mouse clicks etc. again
Hello Bjørnar,
Is the code really running in thread-context?
Good point. He has to check (but I alrady think I mentioned this) that
MultiThreaded is set to True.
Try GetCurrentThreadId to check current thread context.
---
Rgds, Wilfried
http://www.mestdagh.biz
--
To unsubscribe or change
Hello Markus,
For the receiving part I did this (the contents of tthread execute):
udp.MessageLoop;
Are you very sure this is exacly what you want ? MessageLoop will
pump messages, but will actually stay there until a WM_QUIT is received.
If you dont watch carefully you will end up with a
18 matches
Mail list logo