> On 27 Apr 2004, Bill Pringlemeir wrote:

>> The values cause an underflow in the division and the result is
>> zero.  This would seem to happen for any file that is less than the
>> size of the display.  Most people wouldn't download such small
>> files.
 
On Sat, 01 May 2004, [EMAIL PROTECTED] wrote:

> This has now been fixed in CVS. Thanks for the report and for
> digging up the causes.

I tried revision 1.12 of visual_progress_gui.c.  I also updated all of
the rest of the source.  I see these asserts,

        g_assert( v->context->width );
        g_assert( v->file_size);

The problem is still occurring.  I have the following core
directories,

    core2004.04.25.22.09.22/
    core2004.04.26.19.03.38/
    core2004.04.26.19.09.31/
    core2004.04.26.21.16.14/
    core2004.05.01.19.49.45/    <- updated from CVS.
    core2004.05.01.19.54.12/    <- updated from CVS.

An assert to catch this problem would be like this,

        g_assert( v->file_size > v->context->width);

The file size is so small that the division causes `bpp' to be zero.
Another alternative would be to use,

        g_assert(bpp);

I tried this code modification,

     bpp = (v->file_size + v->context->width/2) / v->context->width;

This seems correct to me.  The mathematics should round up any
calculation.  However, when I used this, is still had the division by
zero instruction.  I finally fixed it so that I could delete these
files by inserting this line,

     bpp = (v->file_size + v->context->width) / v->context->width;

I have now deleted the files which remain in the download list across
runs and which always crashed GTKG whenever I clicked on them.  This
fix caused an display anomaly in the progress bar when I clicked on
the small file, but it did not crash GTKG.  Other files appear to be
ok.

Now, the reason "/2" doesn't work also makes sense to me.  It must
round up.  The other version I had just made a normal round off.  So a
very small file is still zero.  The "/2" will only make a file size
greater than half the progress bar pixel width work.  Of course this
change may cause some off by one draw error.  It seems that GTK1 will
clip these; but you might have a better solution?

Regards,
Bill Pringlemeir.



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Gtk-gnutella-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

Reply via email to