Subject: Re: Topic: Tables and 1.0
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Mon May 07 2001 - 02:51:59 CDT
On Sun, 6 May 2001, Leonard Rosenthol wrote:
>
> I'm confused. Why are number of rows/columns tracked in the
> table, but their size is in the cell? And is this size the CURRENT size or
> the defined size (ie. if the user said that he wanted a cell width==20%,
> what gets stored - the 20% or the actual resolution of that value)? And if
> that info is in each cell, that potentially means a LOT of iterating of
> cell data to compute cursor, etc. locatons.
>
Yeah. It's proabablly better to put that in the table definition.
> Also, what about cell attributes & formatting info (text
> alignment, background color, borders, etc.)? And are tab stops relative to
> a cell or relative to the page?
>
Cell's know about their own formatting properties only. These are relative
to the containg section.
> Something else to consider. If allow cross-cell selection (ie.
> some text in one cell and some text in another), what happens when you then
> hit "Backspace"?
>
>
An interesting example. The PieceTable would report an attempt to delete a
CELL strux. At this point we could ask the use if she really want to to
merge two cells. If so we continue with appropriate code to update overall
TableStrux.
As a first past we could just ignore Cell strux delete across a cell
boundary and just remove the text.
> >We will extend these manipulations to allow cell strux changes
> >(populate/change/insert/delete) these map to CallSectionLayout.cpp
> >
> >and table strux changes (populate/change/insert/delete) these map to
> >TableSectionLayout.cpp.
>
> What about attribute information (see above)?
>
This is obtained from the TableStrux and CellStrux the same way our
present sections do it. The layouts are notifyed on every change of the
underlying PieceTable. This part of abi's Model-View scheme works well.
Cheers
Martin
This archive was generated by hypermail 2b25 : Sat May 26 2001 - 03:51:03 CDT