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:
>
>> Very strange, I never hit this one in 2009+, however I'm runing the
>> IDE on Windows 32-bit. If you look at the source code you'll find
>> that global variable GUnitFinalized is set to TRUE in Finalization
>> section. Since globa
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
On Mar 28, 2010, at 13:00, Arno Garrels wrote:
> Very strange, I never hit this one in 2009+, however I'm runing the IDE
> on Windows 32-bit. If you look at the source code you'll find that
> global variable GUnitFinalized is set to TRUE in Finalization section.
> Since global variables ought to
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
Jon Robertson wrote:
>
> When opening a form that contains ICS components, I received this
> exception from the IDE:
>
> Error Reading Form
>
> Unit is already finalized, check your threads!!
> (S:\Components\D2009\ICS\Delphi\Vcl32\OverbyteIcsWndControl.pas
> line 497). Ignore the error and con
I sent this a couple of days ago, but I didn't see it come through the
list. My apologies if you received a duplicate message.
-- Forwarded message --
From: Jon Robertson
Date: Fri, Mar 26, 2010 at 12:53 PM
Subject: Unit is already finalized, check your threads!!!
To: ICS support
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
Arno Garrels wrote:
> My sample above as two Unicode code points:
>
> UStr := #$FF5E#$FF5E;
>
> Try to convert this string with WideCharToMultiByte() to ansi code
> page 50220, the result is two question marks "??". Both MLang's
> ConvertINetUnicodeToMultybyte() and iconv give the correct result.
Francois PIETTE wrote:
> In which context do you have such a need of on-the-fly conversion ?
> Are you trying to display an email content while it is being
> transfered ?
It's required in TMimeDec for example, the parser reads from stream into
a buffer of fixed length. So it is possible that at
19 matches
Mail list logo
