On 11/16/2010 09:20, Michele Zarri wrote:
On 16/11/10 09:04, TJ Frazier wrote:
Hi, all,
I've been puzzling over my test results from Michele's banding code.
It works, in the sense that the code runs without error, and the
assigned color value is stored by Writer, and reappears on
load-after-save. The one problem is that in my test tables (from
0219WG3 Keyboard Shortcuts, with the latest [March?] 3.2 template,
under 3.2.1) the newly-assigned value often fails to appear on the
screen :-( Bah! Humbug!
@Jean: Can you confirm that the following procedure is the way you
create the banding in the first place?
Hover in the left margin until the tooltip and arrow appear for
"Select table row", and click. Table > Table properties > Background
tab to select color (Gray 10%, white, No fill). Click OK.
What I have found is that every row must be set (once) by this method
to "no fill" in order for the macro to work. Setting the
Rows(...).BackColor property will not override the manual setting, but
the property is set, and takes effect as soon as the manual setting is
set to "no fill". The manual cleanup is entirely feasible; banding is
alive and well!
@Michele, Andrew: any ideas where the "real" (manual) back color
setting can be found, programatically? Doing the cleanup by hand is
feasible, but not desirable.
Notes:
(1) the "OOoTableHeader" paragraph style in the template must be
changed not to set the header background color, if we want to set that
here (in the macro).
(2) the border width, as specified in the macro, is in units of
1/100th of a millimeter(!). A value of 35 is approximately one point.
The distinction between values of 2, 4, and 8 seems to be completely
lost on screen display. I solicit input from anyone who knows whether
these small values are meaningful for printing or other export, and
whether there is any discernible aesthetic difference to you.
Hello TJ,
I am currently on a business trip so with limited time to look into it,
but I as you correctly guessed the problem seems to be that the cell
background has been set and that value takes precedence over the row
background (which in turn takes precedence over the table background.
I guess it may be sufficient therefore to add to a macro a firs
iteration through the cells (obtaining a cell object) and setting the
background to "no fill".
If I find some time I will provide a subClearCellBackgrounds( oTable As
Object) some time this week, though I will have to discover first how to
set the background to "no fill".
On the notes:
(1) agreed.
(2) thanks for the additional info. I was not quite sure what the units
of measurement were.
Cheers,
Michele
Got it, thanks. Once you told me where to look, the problem was easy.
Operative code extract:
Const lNoFill As Long = -1
For nIndex = Lbound(vNames()) To Ubound(vNames())
oCell = oTable.getCellByName(vNames(nIndex))
oCell.BackColor = lNoFill
Final beautification and testing underway. I should be ready to ship my
suggested revisions in a day or two. I have tried to optimize for
maintainability; feel free to change anything you don't like.
Has everyone agreed that the proper home for this is in the chapter
template? If so, do you want to put it there, or should I?
--
/tj/
---------------------------------------------------------------------
To unsubscribe, e-mail: authors-unsubscr...@documentation.openoffice.org
For additional commands, e-mail: authors-h...@documentation.openoffice.org
