Re: commit: Step towards nested tables.

From: j.m.maurer (
Date: Mon Jul 29 2002 - 08:19:55 EDT

  • Next message: Jordi Mas: "Error building BMP plugin for win32"

    > Great! Thanks. Upon further inspection of what you've done for
    > clearScreen() for cells, I really think you've taken the wrong path.
    > clearScreen() should just call down to all the containers within the
    > cell calling clearScreen() on each of the containers with the cell.
    > These are eventually resolved to fp_Line::clearSceen() which actually
    > paints over the line with the background color.
    > They used to work this way.
    > ie
    > fpContainer * pCon = getFirstContainer()
    > while(pCon)
    > {
    > pCon->clearScreen();
    > pCon = pCon->getNext();
    > }
    Erm, you totally puzzling me here.. All the code in clearScreen (except
    for line 235 is _your_ code!! Looking at revision 117, you'll see I only
    changed this line from clearLines() into (the new function) _clear()
    which does the same as the cleanLines() AND it also clears the
    background color.

    Also the code you describe above is just there in clearScreen(): look at
    lines 213-219 ... Again, this is your code, not mine

    > Also I used to have a method clearLines() which just paints over the
    > lines drawn with drawLines() with background color. I put private member
    > variables to store the corners of the lines of cell with the cell. This
    > code has also been removed. I really think the way clearLines() worked
    > is the right way to do this.
    erh, no no :) your code is still used (with 1 little mistake I now see)
    but I moved it into the function _getBrokenRect(). I'll clearify this
    code a bit, so it looks much more sane

    > Background color of the cells should be set inside the fp_CellLayout as
    > the the screen color. When runs and lines chainup to find the
    > background color, they get the color inside the cell.
    runs don't chain up to find the background color, they just take the
    page color (look in updateHLColor in pf_Run())! What we _should_ do,
    I'll describe in a seperate mail sometime in the future when I find the

    > Doing things this way nicely isolates each component of the application.
    > This greatly aids maintainabilty of the application and allows this sort
    > of nesting with different colors images in each cell or table.

    Exactly! Can't agree with you more

    > Also the table cell controls on the top ruler don't work right now. If
    > you attempt to drag a control nothing happens.
    Hmmm, this seems to be a GTK2 related buggie... maybe I can fix it...


    This archive was generated by hypermail 2.1.4 : Mon Jul 29 2002 - 08:26:24 EDT