Hello,
I personnaly always create and manage the socket component in a
separated thread. This permit to avoid such problem, and also when the
reverse appear when your socket procedures has a very high activity
that could slow down the main's app message queue that make it less
responsive (or near freezed).
regards.
>> I have observed that Windows does not pass messages to an application when
FP> certain User Interface functions are active. Examples are an open drop-down
FP> menu or a user dragging a window. This can cause ICS functions such as this
FP> Socket Open code to fail:
>>
>> { Use while to repeat connects to ensure enough time for reset to end }
>> tTarget := Time + ((FiResetTime / 1000.0) / 86400.0);
>> while not FfConnected and (Time < tTarget) do begin
>> FiLastError := SocketConnect; { Sets FfConnecting }
>> if FiLastError = FX_OK then
>> begin
>> { FfConnecting is cleared by FWSocketSessionConnected, may happen
FP> on
>> socket connection timeout }
>> while FfConnecting do
>> Application.ProcessMessages; { This can be
FP> FWSocket.MessagePump; }
>> end; {if FiLastError=FX_OK}
>> end; {while not connected}
>>
>> With a drop-down menu open, this will run as for long as FiResetTime is
set (>> 30 seconds) without connecting.
>>
>> Is there a way to make Windows continue to pass messages even if a
FP> drop-down menu or other UI function is active?
>>
>> Thanks,
>> John
>> --
>> To unsubscribe or change your settings for TWSocket mailing list
>> please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
>> Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
