🚀 go-pugleaf

>> Are you calling Get() in the context of the main thread?  If so, then the
>> freeze is to be expected.
It is if I wasn't calling ProcessMessages() in the OnWork event.

I plan on moving all of that work out of the event, it was just a quick
conversion from TNMHttp over to TIdHTTP to see if that could correct
the problem with it freezing.


>> The ContentStream->Position is always at the end of the stream
Not true, it updates as the data is received. I'm using this
method because of another post by you that says AWorkCount
is not accurate if the data is sent in different chunks. From my
testing the ContentStream->Size (which is what you said
to use in that other post) is set to the same size as the ContentLength.
when the transfer is started. The Position updates as that data is received.

>> Then your thread code was likely wrong to begin with.
It was the same code except it was inside a Tthread. The UpdateStatus
function was synchronized for access to the main forms visual controls.
DLResult, IsDownloading and Retry all were public variables of the thread.

>> That code has a memory leak if either TIdHTTP::Get() or
>> TMemoryStream::SaveToFile() fail.
Would an auto_ptr take care of that? I'm still looking for a good place
to learn about them.

Thanks,

Tom




"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:43d57fba$1@newsgroups.borland.com...
>
> "Tom" <thomasf1021@hotmail.com> wrote in message
> news:43d571a6$1@newsgroups.borland.com...
>
>> The next file that gets downloaded is 24MB and as soon as the
>> Get is called the program freezes solid.
>
> Are you calling Get() in the context of the main thread?  If so, then the
> freeze is to be expected.
>
>> I do have the AntiFreeze component on the form, and on my machine
>> that doesn't lock up it functions just fine with being able to move the
>> window, click buttons etc without it appearing to be frozen.
>
> TIdAntiFreeze is not perfect.  A better solution would be to move the
> downloading into a separate worker thread instead.
>
>> On his, it's locked up solid, can't move the windows, click the cancel
> button, nothing.
>
> Then TIdHTTP (or something else in your code) has been completely blocked
>> to the point where TIdHTTP cannot even call into TIdAntiFreeze at all.
> Again, you should move the download into a separate thread.  At least that
> way, the program will not be frozen even if such a blockage occurs again.
>
>> I have the OnWork event setup to calculate the current progress
>> of the transfer using the Http1->Response->ContentStream->Position
>> and the ContentLength variables.
>
> The ContentStream->Position is always at the end of the stream  You should
> be using the AWorkCount value that is provided by the OnWork event 
> instead.
> That is the total number of bytes that have been transferred since the
> beginning of the transfer.
>
>> With a Application->ProcessMessages() thrown in to update
>> the display.
>
> TIdAntiFreeze calls ProcessMessages() internally.  Or, if you move the 
> code
> into its own thread, then ProcessMessages() is not needed at all.
>
>> Initially I had it setup in a thread for the downloading with
>> synchronize calls for updating the display, but rather than lockup,
>> the thread was just dying without any errors being thrown.
>
> Then your thread code was likely wrong to begin with.  Please show what 
> you
> were doing.  Also keep in mind that TThread swallows uncaught exceptions, 
> so
> if you want an exception to be reported, you have to catch the exceptions
> yourself so that you can respond to them accordingly.
>
>> bool Download(AnsiString const FileName, AnsiString const FullPath)
>
> That code has a memory leak if either TIdHTTP::Get() or
> TMemoryStream::SaveToFile() fail.  You are also doing a lot of processing
> inside the OnWork event handler.  You might consider streamlining the code
> better to reduce the numbr of placesd where errors can occur.
>
>
> Gambit
>
>