From: Martin Sevior (msevior_at_seviorpc.ph.unimelb.edu.au)
Date: Tue Apr 06 2004 - 23:33:47 EDT
On Tue, 2004-04-06 at 21:18, Marc Maurer wrote:
> just wondering: why is this so complicated? A HdrFtr is just a section,
> right? So clueless me would be thinking that if a Table can be in a
> 'normal' section, it can too in a HdrFtr section (which should just be a
> smaller 'normal' section placed at the top of the page...).. maybe you'd
> need 2 or 3 lines of code, but nothing more...
>
Hi Marc,
As you no doubt guessed if that's all that was needed I would
have done it long ago :-)
The problem is substantially harder because of the different layers of
containers we use for HdrFtr's.
Every page has a "shadow" copy of the an overall HdrFtr. Like this
HdrFtr_SectionLayout
|
------------------------------------------------------
| | | | | |
Page 1 Page2 Page3 Page4 Page5 Page6
| | | | | |
fl_HdrFtrShadow fl_HdrFtrShadow fl_HdrFtrShadow
| | |
fp_ShadowContainer fp_ShadowContainer fp_ShadowContainer
So when example you press a key while editting a HdrFtr, the character
is first inserted into the HdrFtr_SectionLayout which then
Broadcasts it out to all shadows which in turn then update their own
containers on each page.
Now when we put a table into the HdrFtr_SectionLayout we have to
broadcast out all the tables and cells of the tables into the shadows.
So the table and cells inside the HdrFtr_sectionLayout has to duplicate
itself in all the shadows. This is done now.
Now if we press a key inside a cell, the container immediately above the
block we insert the character into is a cell. We have to put in code in
the handlers to detect whether the cell is inside a HdrFtr. If it is
then it has to find the HdrFtr then broadcast all the info out to all
the shadows on each page. I've almost finished this part.
On top of that there is some special case logic that (used) to assume
that a table was inside a column because we allow continuous section
breaks and tables broken over pages. When this happens the offsets for
the break point in the tables changes. So I had to fix that up too.
Plus I had to take out the blocks that prevented users from inserting
Tables into Header/Footers. (This isn't implemented for the importers
yet.)
Finally there is the meta-problem of making sure all the pointers and
memory management is taken take of as we add or delete pages. When we do
this we also now add and delete tables and cells. It took a long time to
get all this right for just adding new blocks and lines. I hope it won't
take much more work to get it right for Tables and Cells. So far things
seem to be OK but I suspect there will be problems here.
So I hope you can see this is a fair of work but I think it is not as
bad as making nested tables break across pages.
Cheers
Martin
> Marc
>
>
> On Tue, 2004-04-06 at 05:15, Martin Sevior wrote:
> >
> > CVS:
> > ----------------------------------------------------------------------
> > CVS: Enter Log. Lines beginning with `CVS:' are removed automatically
> > CVS:
> > CVS: Committing in .
> > CVS:
> > CVS: Modified Files:
> > CVS: src/text/fmt/xp/fl_BlockLayout.cpp
> > CVS: src/text/fmt/xp/fl_ContainerLayout.cpp
> > CVS: src/text/fmt/xp/fl_ContainerLayout.h
> > CVS: src/text/fmt/xp/fl_DocListener.cpp
> > CVS: src/text/fmt/xp/fl_SectionLayout.cpp
> > CVS: src/text/fmt/xp/fl_SectionLayout.h
> > CVS: src/text/fmt/xp/fl_TableLayout.cpp
> > CVS: src/text/fmt/xp/fp_Column.cpp
> > CVS: src/text/fmt/xp/fp_ContainerObject.cpp
> > CVS: src/text/fmt/xp/fp_TableContainer.cpp
> > CVS: src/text/fmt/xp/fv_View.cpp src/wp/ap/xp/ap_LeftRuler.cpp
> > CVS: src/wp/ap/xp/ap_Menu_ActionSet.cpp
> > CVS: src/wp/ap/xp/ap_Toolbar_ActionSet.cpp
> > CVS:
> > ----------------------------------------------------------------------
> > Very basic support for Tables in Headers/Footer. Lots more work needed.
> > The table goes in but you can't type in it yet.
> >
> > Cheers
> >
> > Martin
This archive was generated by hypermail 2.1.4 : Tue Apr 06 2004 - 22:45:05 EDT