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.
--
/tj/
---------------------------------------------------------------------
To unsubscribe, e-mail: authors-unsubscr...@documentation.openoffice.org
For additional commands, e-mail: authors-h...@documentation.openoffice.org
