Just wondering about the implications of this thread to ICS in general.
As a Delphi user of ICS, are there DLL concerns for other non-SSL parts
of ICS?
Francois PIETTE wrote:
Altough using in in Delphi is even more interesting, I was just
thinking about publishing the procedure to rebuild
CanClose := False;, the server does not work after this event.
What causes background exceptions?
Arno Garrels wrote:
Mike Lenox wrote:
That's good information. I am not surprised if the TTimer is mine.
BUT, the issue is still that I only get the error when I have both ICS
components
Finally! A very simple bug causing very strange symptoms. I had
overridden Destroy in my ClientInstance object and neglected to include
a final call to the inherited Destroy.
Arno Garrels wrote:
Mike Lenox wrote:
I am aggressively debugging the application. The root problem at this
point
In my current app, I only have a main thread. So, does this, ...this
may cause a lot of trouble, apply? I should expect trouble if I have
multiple ICS components all executing on the main thread?
Original Message
Subject:Re: [twsocket] Conflicts between multiple
I guess I am not being very clear.
I am not creating other threads. I only have one ... the main Delphi thread.
I am creating different ICS components, a TTnCnx client and a
TWSocketServer in separate parts of my application. There are no shared
global variables and the two instances are in
wrote:
Mike Lenox wrote:
BUT, the two objects seem to be interacting with each other as I get a
TTimer access error ONLY when both objects are active and I make an
actual connection to the server.
Both TWSocketServer and TTnCnx do not use a TTimer. If your code uses a
TTimer what
Is there a problem having multiple instances of ICS socket objects on
the same thread? I have a Delphi app (single threaded) with different
ICS-based objects in various units. I saw today what looked like
crossover functionality between some of them. I'm getting TTimer access
violation errors
More info concerning my original problem which is ...
My application uses a TTnCnx client object to connect (hundreds of times
per day) to a remote device to retrieve data. On rare occasions the pair
seem to get stuck in a connected state and stay there indefinitely.
The normal procedure is
I have an application that uses a TTnCnx object to repetitively retrieve
data from a remote device. The application keeps a TTnCnx object and
alternately Connects and Closes. I am having an occasional problem with
the connection getting latched up, that is, it doesn’t seem to close
properly
Francois,
Thanks you for the quick reply. I do not call Connect from the Close
event but, the events that cause data to be requested are asynchronous
and a request could occur almost immediately after a Close. So, I am
wondering of I should be concerned that my TTnCnx object is still in the
that you publish the call stack at the time when you
cann connect after the close.
--
francois.pie...@overbyte.be
The author of the freeware multi-tier middleware MidWare
The author of the freeware Internet Component Suite (ICS)
http://www.overbyte.be
- Original Message -
From: Mike
11 matches
Mail list logo
