Piotr Dałek wrote: > Hello! > >>>>>> A reliable way to calculate More was >>>>>> "More := Stream.Position < Stream.Size;" >>>>>> >>>>>> however that is slower since Stream.Size has to seek to the end >>>>>> of the stream and the back to current position on each call of >>>>>> DoFileEncBase64(). (Instead of Stream.Size we could also check >>>>>> against file size, however only with ShareMode fmShareDenyWrite). >>>>> >>>>> var >>>>> LocalStreamSize: integer; >>>>> [..] >>>>> LocalStreamSize := Stream.Size; >>>>> [..] >>>>> More := Stream.Position < LocalStreamSize; >>>>> [..] >>>>> >>>>> Problem solved. >>> >>>> I do not get this, sorry. Please elaborate. >>> >>> Get the stream size only once - store it somewhere and use stored >>> value instead of calling Stream.Size getter. > >> OK, but what will happen if the stream size changes during encoding, >> if for instance the component user opened the file with ShareMode >> fmShareDenyRead? > >> That's why I added public property Mode to the TBufferedFileStream >> class and >> check the ShareMode in DoFileEncBase64,. in case of no problem >> TBufferedFileStream(Stream).FastSize is called (which is current, >> constant size), otherwise Stream.Size (which is slow, but who will >> actually open a file to be sent with ShareMode fmShareDenyRead only >> ? I guess not many). > > The only reason for this is creating attachment (file to be encoded) > while > it is actually encoded, but then, using the mechanism available in > ICS is a > waste of disk space (already encoded original data still reside on > disk). > I think that all users will use simple files containing ready data > that is > not going to be changed during encode process. Supporting other > scenarions > is overkill, at least for me. If you don't agree, then what if you > buffer > (in TBufferedFileStream) 1024 bytes, encode first 50, then (somehow) > next > 100 bytes changes? You still have outdated 100 bytes in the buffer. > Then > what? Bug, no matter what! > So why should you care about size change, > if > you don't care about actual file changes? I don't think that you're > going > to support *that* scenario.
True :) But unfortunately it is possible to set fmShareDenyRead and fmShareDenyNone:( I wish there were just two ShareModes provided, fmShareDenyWrite and fmShareExclusive. -- Arno Garrels > -- > Piotr Dałek > enigmati...@interia.pl > > ---------------------------------------------------------------------- > Promocja w Speak Up. 3 miesiace angielskiego gratis. > Sprawdz teraz i wypelnij formularz! >> http://link.interia.pl/f2019 -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
