Re: [pilot-db-list] More beta 8 buglets

[Mike R. <mik...@al...>]

On Fri, 22 Feb 2002, Scott Wallace wrote:
> > 4) The floating type seems to be padded by several spaces on the right
> > hand side. I.e. when adjusting the view, there is always about 10 pixels
> > of white space after the 1 decimal place I set. If I attempt to squeeze
> > the white space, then numbers change to "..." indicating it doesn't fit.
>
> Yes, this is true.  There is a 10 pixel margin on the right side of a
> float column.  If there is no margin, what happens is that the float is
> directly adjacent to the value in the next column (since most columns are
> left justified) ...
> you could make the margin disappear as the the column becomes increasingly
> full.  But this requires calculating the max width overall columns, which
> is too slow.  So instead, I just use a constant value.

Is it that slow? I guess the real question is how often the value would
have to be recalculated. If it can be calculated only when the DB is
opened, it should be tolerable. (You may then have to close and reopen the
database to get it to update correctly.) I would think that calculating
the maximum width of one of the elements, right justifying each element
within this box width, then _left_ justifying boxes within the column
based on the width given in the list view would be the best way to attack
this.

> If you have a better metric in mind, I will consider it, but it is
> important that the display does not become hard to read.

As a lower order step, what about an extra parameter next to the "number
of digits" selection which sets the padding space (default 10)? That way,
you can keep your fixed width, and I can smash my data as close as
possible :-) Also, any chance the number of digits can be set per database
or even per column? I could definitely use varying precision in some
completely unrelated databases that I have.

Mike

-- 
Mike Ressler
mik...@al...
OK, I'm lame: I don't have my own website ...