On Jul 15, 12:05 am, ChartMan <[email protected]> wrote:
> The table is not designed for resizing as it relies on its dimensions on the
> time of drawing.
Fair enough. But in that case, the bug is that it is resizing the data
columns when it shouldnt be :-)
> Its dimension are controlled by the user specified options 'width' and
> 'height'.
Right. Thats what Im using...
>
> If you wish to resize the table then call the table.draw again with the new
> parameters.
Again... thats my workaround - but the table still looks odd while its
parent div is being resized because the data columns resize fluidly,
but the column headers remain fixed.
> If this becomes widely used I may consider adding this internally to the
> table code. However, in any case, the
> draw method will be invoked again as partial execution is not possible.
And yet... html tables do exactly what I want, with no help. *Your*
table does exactly what I want, if I specify neither height nor width.
I think I see what the issue is - in order to prevent the header from
scrolling, you've actually created it as a separate table (but only
when "height" is specified). But then you have to manually force the
header columns to be the same width as the data columns.
But it seems to me that "partial execution" would be very possible - a
"postResize" method would only need to recalculate the header column
widths - the rest of the table is taking care of itself...
Mark
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Visualization API" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/google-visualization-api?hl=en
-~----------~----~----~----~------~----~------~--~---
