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 Open
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
, though my
handler has "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 er
rrels 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 i
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 di
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 ins
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 t
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 to
t;
> - Original Message -
> From: "Mike Lenox"
> To: "ICS support mailing"
> Sent: Thursday, April 30, 2009 5:08 PM
> Subject: Re: [twsocket] TTnCnx
>
>
> Francois,
>
> Thanks you for the quick reply. I do not call Connect from the Close
> event
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
pr
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 and
11 matches
Mail list logo
