Thanks Remy
> You should not be sharing a single stream across multiple threads that are
> manipulating the stream's content at the same time. If the download
stream
> is writing the data to a file on the hard drive, then the parser thread
> should be using its own separate stream that has the same file opened for
> reading only. That way, the parser can maintain its own separate position
> tracking in the file, without worrying about messing up the downloading
> stream's own position tracking.
>
- Yes - that's exactly what I do. I use two independet file streams. One for
the thread which "Gets" and one for the parser. So no issue with this.
> Simply do not have your parser process the file until after Get() has
> exited, indicating that the download is finished. You are starting your
> parser too soon.
- The file is large in size (may reach 10MB even more). So waiting for Get()
to complete is not an option here.
Actually my client application registers a custom protocol to handle these
files. Like "elcplay://xyz.com/thefile.ers"
So my intention is to make it similar to a video player (the content is not
video but a prerecorded live session anyway...)
Now the best thing in this case will be as you suggested to overwrite the
TStream so that it triggers some events on each new block complete.
Another approach I am thinking of is use idTCPClient to implement a custom
"Get" method with the required functionality and events.
Thansk for your advice.
Regards
