Francois PIETTE wrote:
You are forgetting to free the memory. See TCustomLineWSocket.Destroy
about how to do it properly.
Wait, something just occurred to me: FRcvdPtr is of type TWSocketData,
which is an Array Of Bytes, i.e. a dynamic array.
No, it is of type pointer when win32 is defined w
You are forgetting to free the memory. See TCustomLineWSocket.Destroy
about how to do it properly.
Wait, something just occurred to me: FRcvdPtr is of type FRcvdPtr, which
is an Array Of Bytes, i.e. a dynamic array.
No, it is of type pointer when win32 is defined which is the case.
--
franco
On Mar 29, 2010, at 00:50, Francois PIETTE wrote:
> You are forgetting to free the memory. See TCustomLineWSocket.Destroy about
> how to do it properly.
Wait, something just occurred to me: FRcvdPtr is of type FRcvdPtr, which is an
Array Of Bytes, i.e. a dynamic array. According to the Delphi
On Mar 29, 2010, at 03:39, Jon Robertson wrote:
> I should have only included FRvcdCnt := 0; That will prevent
> TriggerSessionClosed from calling TriggerDataAvailable, and allow
> TCustomLineWSocket.Destroy to free the buffer, rather than having multiple
> code snippets that free the buffer, wh
Thanks. As I mentioned earlier, it's been a while since I've spent any time
in the ICS source. :(
I should have only included FRvcdCnt := 0; That will prevent
TriggerSessionClosed from calling TriggerDataAvailable, and allow
TCustomLineWSocket.Destroy to free the buffer, rather than having mult
I like Francois' idea to implement TCustomLineWSocket.InternalAbort and
use
it to clear TCustomLineWSocket's buffer, doing some or all of:
FRcvdPtr:= nil;
FRcvBufSize := 0;
FRcvdCnt:= 0;
At a minimum, setting FRcvdCnt := 0 will prevent TriggerSessionClosed from
calli
TCustomLineWSocket.TriggerSessionClosed does not know in this scenario that
the session is being closed because Abort was called.
I like Francois' idea to implement TCustomLineWSocket.InternalAbort and use
it to clear TCustomLineWSocket's buffer, doing some or all of:
FRcvdPtr:= nil;
That sounds like an excellent solution to this particular situation. So
simple, I'm ashamed I didn't suggest it first. :)
On Sun, Mar 28, 2010 at 2:13 PM, Francois PIETTE
wrote:
> Abort call InternalAbort which do not clear the buffer where
> TCustomLineWSocket store received data to break it i
On Mar 28, 2010, at 14:04, Arno Garrels wrote:
> And that's IMHO nonsense, Abort should just throw away and free
> buffered line-data TCustomLineWSocket.SessionClosed should call
> inherited SessionClosed silently in this case, or am I missing the
> point?
I think you are right.
dZ.
As you noticed, when you turn off LineMode in your code, it will not
re-enter OnDataAvailable. I'm not sure why the distinction at this point.
Abort call InternalAbort which do not clear the buffer where
TCustomLineWSocket store received data to break it into lines. I suspect
that TCustomLine
DZ-Jay wrote:
> On Mar 28, 2010, at 13:00, Arno Garrels wrote:
>
>> It sounds indeed somewhat strange that Abort triggers DataAvailable.
>> In general, when I call Abort I do not expect to receive any more
>> data but actually want to stop all ongoing processing asap.
>
> Abort() calls InternalAb
On Mar 28, 2010, at 13:00, Arno Garrels wrote:
> It sounds indeed somewhat strange that Abort triggers DataAvailable. In
> general, when I call Abort I do not expect to receive any more data but
> actually want to stop all ongoing processing asap.
Abort() calls InternalAbort(), which calls Int
Markus Humm wrote:
> hello,
>
> shouldn't the receivestr or similiar methods mark the buffer as being
> processed so there never ever is any need for calling OnDataAvailable
> again? (unless new data has been received on the socket)
> I just don't understand the architecture and the why it is don
hello,
shouldn't the receivestr or similiar methods mark the buffer as being
processed so there never ever is any need for calling OnDataAvailable
again? (unless new data has been received on the socket)
I just don't understand the architecture and the why it is done in this way.
Greetings
Mark
On Mar 28, 2010, at 07:32, Jon Robertson wrote:
> The TriggerSessionClosed (not sure the exact function without looking it up)
> was not "aware" that OnDataAvailable had already been called for the current
> data. It was only "aware" that there was data that had not been processed
> and the sock
On Mar 28, 2010, at 04:27, Markus Humm wrote:
> I never really understood why OnDataAvailable isn't called in a way
> which hinders such reetrancy problems. Isn't the Windows message which
> triggered it taken off the message queue by then? If not, why not?
The problem is that it is not just a m
In my scenario, OnDataAvailable wasn't called the second time because of the
message queue. The socket was being closed, and RcvdCnt > 0, so
OnDataAvailable was being called to handle the remaining data.
Since my first OnDataAvailable had not finished before the exception
occurred, the "metadata"
Hello,
I never really understood why OnDataAvailable isn't called in a way
which hinders such reetrancy problems. Isn't the Windows message which
triggered it taken off the message queue by then? If not, why not?
Greetings
Markus
--
To unsubscribe or change your settings for TWSocket mailing lis
On Mar 27, 2010, at 17:34, Jon Robertson wrote:
> dZ: Perfect understanding. :)
The same happened to me a couple of years ago (as you point out in your
previous post). I couldn't fix it then and just made sure that I handle all
errors in my OnDataAvailable handler.
> While the exception in
dZ: Perfect understanding. :)
While the exception in #3 is the application's fault (my fault), I'm relying
on OnBgException to be triggered if an exception occurs inside my
OnDataAvailable event. Either I shouldn't do this and ICS users should put
their own exception handling inside OnDataAvail
On Mar 27, 2010, at 13:21, wilfried Mestdagh wrote:
> These are possible untested situations. It is possible to call Abort from
> within an event, but why should you call Abort if the session is closed?
I think that he means that if there is an exception in the OnDataAvailable
handler, and you
sts.org] Namens
Jon Robertson
Verzonden: vrijdag 26 maart 2010 9:03
Aan: ICS support mailing
Onderwerp: Re: [twsocket] InternalAbort causes OnDataAvailable *during* the
Abort call
On Fri, Mar 26, 2010 at 2:46 AM, Jon Robertson
wrote:
> In fact, OnDataAvailable has already been called with the exa
You won't be able to reproduce this. This is only occurring because I've
modified the exception handler in ASyncReceive to call
HandleBackGroundException, which in turn calls Abort. The version in SVN
does not call Abort when an exception occurs in ASyncReceive (or associated
event handlers).
I'
On Mar 26, 2010, at 04:02, Jon Robertson wrote:
> To clarify, OnDataAvailable has received complete data, say:
> help\n
>
> In processing that data, an exception occurs and TWSocket.Abort is called to
> abort the connection. Before .Abort returns, OnDataAvailable is called
> again, with the exa
On Fri, Mar 26, 2010 at 2:46 AM, Jon Robertson wrote:
> In fact, OnDataAvailable has already been called with the exact same data.
> If OnDataAvailable is called twice with the same data, but the data was only
> received once, I consider that a bug.
>
To clarify, OnDataAvailable has received comp
In my scenario, the data is "complete" because there are line end
characters.
In fact, OnDataAvailable has already been called with the exact same data.
If OnDataAvailable is called twice with the same data, but the data was only
received once, I consider that a bug.
Thanks
On Fri, Mar 26, 2010
Hi,
It is not a bug, it is by design. The data already received is delivered to
the application. The application can easy check if it is complete data by
checking the line end character(s).
--
mvg, Wilfried
http://www.mestdagh.biz
--
To unsubscribe or change your settings for TWSocket mailing l
When using LineMode, I've determined that calling TCustomWSocket.Abort will
cause my OnDataAvailable event to fire *during* the call to Abort.
My dilemma is that Abort is being called during the handling of an
OnDataAvailable event. While that data is being handled, but before it is
completely ha
28 matches
Mail list logo
