Hi.  I've seen this question asked before, but didn't see a solution posted
in the archives.

I've just compiled the latest beta of ICS, and when I attempt to install the
packages, I get a warning that BCB can not install the package because
bcbie60 already contains the unit shdocvw_ocx. Has anyone seen this before?
Any ideas at resolving it?

Thanks,
Ian

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, October 26, 2005 8:00 AM
To: twsocket@elists.org
Subject: TWSocket Digest, Vol 140, Issue 4

Send TWSocket mailing list submissions to
        twsocket@elists.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://www.elists.org/mailman/listinfo/twsocket
or, via email, send a message with subject or body 'help' to
        [EMAIL PROTECTED]

You can reach the person managing the list at
        [EMAIL PROTECTED]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of TWSocket digest..."


Today's Topics:

   1. Re: Bug in SmtpProt.pas (DZ-Jay)
   2. Re: Bug in SmtpProt.pas (Bj?rnar Nielsen)
   3. Re: Speed and buffered file stream (Arno Garrels)
   4. Re: Bug in SmtpProt.pas (Arno Garrels)


----------------------------------------------------------------------

Message: 1
Date: Wed, 26 Oct 2005 06:35:02 -0400
From: DZ-Jay <[EMAIL PROTECTED]>
Subject: Re: [twsocket] Bug in SmtpProt.pas
To: ICS support mailing <twsocket@elists.org>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=US-ASCII; format=flowed


On Oct 26, 2005, at 06:06, Arno Garrels wrote:

>>
>> So the subject arrives as one continuous line of 1000+ characters?  
>> And
>> the SMPT server permits this? Strange.  I'll take your word for it, 
>> as I have no access to Outlook 2003 to test.
>
> Some mail servers reformat invalid headers and mime messages, with 
> sometimes very strange results. Also some MTA's would drop the 
> connection on receiving very long lines since they assume a buffer 
> overrun attack.

That's what I was alluding at; I was assuming he meant that the message
would arrive intact with the entire subject line without breaks or
truncation.

> One note on OE 6, it truncates the subject line at 266 chars silently.

Outlook 2000 does the same thing, and it won't let you enter a subject line
longer than 256 characters (but it split it with <CRLF>+<TAB> after every 74
chars.)

        dZ.

--
DZ-Jay [TeamICS]



------------------------------

Message: 2
Date: Wed, 26 Oct 2005 12:52:03 +0200
From: Bj?rnar Nielsen <[EMAIL PROTECTED]>
Subject: Re: [twsocket] Bug in SmtpProt.pas
To: "'ICS support mailing'" <twsocket@elists.org>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain;       charset="iso-8859-1"


> 
> That's what I was alluding at; I was assuming he meant that 
> the message would arrive intact with the entire subject line 
> without breaks or truncation.

It does, but I can't write more than 256 chars in the subject-line. The
subject is kept as a single line, no splits. The subject is sent this way
and I receive it back from the mailserver the same way.

Regards Bj?rnar




------------------------------

Message: 3
Date: Wed, 26 Oct 2005 13:03:07 +0200
From: "Arno Garrels" <[EMAIL PROTECTED]>
Subject: Re: [twsocket] Speed and buffered file stream
To: "ICS support mailing" <twsocket@elists.org>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain;       charset="iso-8859-1"

Angus Robertson - Magenta Systems Ltd wrote:
>> I've uploaded a tiny buffered file stream class as well
>> as a simple test program. It is amazing fast when small
>> chunks are read/written. Seeking is slower than TFileStream :(
> 
> I'll try in one of my applications, but it won't be until next week.
> 
> For the FTP server, I often have multiple PCs downloading the same
> files, in some cases 30 or 40 megs.  With the normal TFileStream,
> presumably Windows will be effectively buffering the file once, and each
> separate stream will be reading from common windows buffers, in the
> normal read chunks specified by the server.  I've never really
> understood whether this was efficient, or just simple.
> 
> So what are the implications of buffering the same file multiple times?
> Presumably just the extra memory for the buffer?

You save a lot of API calls. It depends on the ratio of block size and
buffer size. The SmtpCli reads files byte by byte hence it benefits from
a buffered stream enormously.

> 
> I have a couple of special files that are read thousands of times of
> day, both less than 1 meg that I could keep in a memory stream for
> efficiency.

I think that's the fasted way of caching.  

> 
> Angus


------------------------------

Message: 4
Date: Wed, 26 Oct 2005 13:26:12 +0200
From: "Arno Garrels" <[EMAIL PROTECTED]>
Subject: Re: [twsocket] Bug in SmtpProt.pas
To: "ICS support mailing" <twsocket@elists.org>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain;       charset="iso-8859-1"

Bj?rnar Nielsen wrote:
>> That's what I was alluding at; I was assuming he meant that
>> the message would arrive intact with the entire subject line
>> without breaks or truncation.
> 
> It does, but I can't write more than 256 chars in the subject-line. The
> subject is kept as a single line, no splits. The subject is sent this way
> and I receive it back from the mailserver the same way.

That's an old bug in OE, you should not copy M$ bugs but wrap the
subject line. BTW: I think having ~1000 chars for the subject line
is far enough, or do you know a client that would display such long
subjects properly?

Arno Garrels


------------------------------

_______________________________________________
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

End of TWSocket Digest, Vol 140, Issue 4
****************************************


-- 
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to