In the course of trying to help someone on another forum, I have been looking
at Table AutoFormats vs Table Styles and there seem to be some aspects that
don't work properly. I have searched everywhere I know to search and found NO
information at all; perhaps I'm just missing the glaringly obvious.

There used to be a Table AutoFormat feature that applied a pre-defined set
of formatting to a table. When you used it, it set various Properties of the
Table Object (AutoFormatType, ApplyStyleHeadingRos, etc.) which could be
referenced in VBA. It may not have been perfect but it did a job and you more
or less knew where you stood with it. The same feature still exists in Word
2003 (albeit slightly hidden) and still appears to do the same; it doesn't
interact with Table Styles at all.

In Word 2003 (and XP I suppose but I tested in 2K3) there are Table Styles.
There is still a "Table AutoFormat" menu option but it runs the
TableAutoFormatStyle Dialog (which, like the old version, has a Title of
"Table AutoFormat"). The only effect this feature has on the old Table
Properties is that, when you apply a (new format) Style, the AutoFormatType
is set to a value of 1 (wdTableFormatSimple1), and the
..ApplyStyleHeadingRows, etc. properties are set according to the boxes
checked (and acted upon) in the dialog. If you record this action you will
get something along the lines of the following code:

With Selection.Tables(1)
.Style = "Table Grid 4"
.ApplyStyleHeadingRows = True
.ApplyStyleLastRow = True
.ApplyStyleFirstColumn = True
.ApplyStyleLastColumn = False
End With

which is exactly the same as the code example in the Help files. This code,
however, does not carry out the action carried out by the dialog.

If, after doing this, you invoke the old AutoFormat Dialog it shows the
Format as being "Simple 1" along with whatever special formats you previously
applied to the Style. If you go one step further and actually apply an
AutoFormat it does it 'correctly' in as much as the format is applied to the
Table, but it does it by applying the formatting on top of the existing Style
so the Table retains the Style but no longer has the characteristics of the
Style. If you then return to the new dialog it shows the Table as being in
the Style previously set in the new dialog but with the various .Apply...
properties reflecting the action taken in the old dialog.

All this might be no more than a bit of light entertainment, but the real
problem comes when you try to work with the table format in code. It seems
nigh impossible to determine, for sure, what formats a table actually has. If
the AutoFormatType is not 1 then it (probably) correctly reflects the table
and this will (probably) be true for documents created in Word 2000. If the
AutoFormatType is 1 and the table has a non-default style then you can (again
probably) infer that the table has been formatted in XP or 2003 and the Style
is the one which has been used, but it all seems a bit hit and miss.

Is there something obvious I'm not seeing here?

Tony Jollans was telling us:
Tony Jollans nous racontait que :

In the course of trying to help someone on another forum, I have been
looking at Table AutoFormats vs Table Styles and there seem to be
some aspects that don't work properly. I have searched everywhere I
know to search and found NO information at all; perhaps I'm just
missing the glaringly obvious.

There used to be a Table AutoFormat feature that applied a
pre-defined set of formatting to a table. When you used it, it set
various Properties of the Table Object (AutoFormatType,
ApplyStyleHeadingRos, etc.) which could be referenced in VBA. It may
not have been perfect but it did a job and you more or less knew
where you stood with it. The same feature still exists in Word 2003
(albeit slightly hidden) and still appears to do the same; it doesn't
interact with Table Styles at all.

In Word 2003 (and XP I suppose but I tested in 2K3) there are Table
Styles. There is still a "Table AutoFormat" menu option but it runs
the TableAutoFormatStyle Dialog (which, like the old version, has a
Title of "Table AutoFormat"). The only effect this feature has on the
old Table Properties is that, when you apply a (new format) Style,
the AutoFormatType is set to a value of 1 (wdTableFormatSimple1), and
the .ApplyStyleHeadingRows, etc. properties are set according to the
boxes checked (and acted upon) in the dialog. If you record this
action you will get something along the lines of the following code:

With Selection.Tables(1)
.Style = "Table Grid 4"
.ApplyStyleHeadingRows = True
.ApplyStyleLastRow = True
.ApplyStyleFirstColumn = True
.ApplyStyleLastColumn = False
End With

which is exactly the same as the code example in the Help files. This
code, however, does not carry out the action carried out by the
dialog.

If, after doing this, you invoke the old AutoFormat Dialog it shows
the Format as being "Simple 1" along with whatever special formats
you previously applied to the Style. If you go one step further and
actually apply an AutoFormat it does it 'correctly' in as much as the
format is applied to the Table, but it does it by applying the
formatting on top of the existing Style so the Table retains the
Style but no longer has the characteristics of the Style. If you
then return to the new dialog it shows the Table as being in the
Style previously set in the new dialog but with the various .Apply...
properties reflecting the action taken in the old dialog.

All this might be no more than a bit of light entertainment, but the
real problem comes when you try to work with the table format in
code. It seems nigh impossible to determine, for sure, what formats a
table actually has. If the AutoFormatType is not 1 then it (probably)
correctly reflects the table and this will (probably) be true for
documents created in Word 2000. If the AutoFormatType is 1 and the
table has a non-default style then you can (again probably) infer
that the table has been formatted in XP or 2003 and the Style is the
one which has been used, but it all seems a bit hit and miss.

Is there something obvious I'm not seeing here?

Not being a big fan of pre-defined formats (I always format my table
manually, I never apply an auto format), I am not all that familiar with
Auto-Format.
OTOH, I am very familiar with styles, so when table styles were introduced I
tried to use them, and then gave up as they are at best a good idea that
went wrong. I cannot get them to work reliably, they conflict with paragraph
styles and the Normal style seems to have some veto power on character
formatting that drove me insane. If you use a table style, then manually
format some of the content before copying/pasting the table, you often lose
that manual formatting in the target destination after having pasted the
table. AFAIAC, table styles are a mess.

Until I hear otherwise, I do not use table styles anymore. I use the default
Table Grid style, and in some cases, I even change the template to Table
Normal as this style even has less of an impact on manual formatting,
especially when doing Copy/Paste jobs.

So, if I want to format a table through VBA, I do it the old fashion way. I
set the borders and size with explicit statements and use paragraph styles
to format the textual content. This way I am 1000% certain that the table
will end up looking as I want it to be.


--
Salut!
_______________________________________
Jean-Guy Marcil - Word MVP
ISTOO
Word MVP site: http://www.word.mvps.org

I don't use VBA, but aside from that, I would echo everything Jean-Guy has
said. I format tables manually, starting with Table Normal and applying
paragraph styles as required.

--
Suzanne S. Barnhill
Microsoft MVP (Word)
Words into Type
Fairhope, Alabama USA
Word MVP FAQ site: http://word.mvps.org
Email cannot be acknowledged; please post all follow-ups to the newsgroup so
all may benefit.

"Jean-Guy Marcil" wrote in message
...
Tony Jollans was telling us:
Tony Jollans nous racontait que :

In the course of trying to help someone on another forum, I have been
looking at Table AutoFormats vs Table Styles and there seem to be
some aspects that don't work properly. I have searched everywhere I
know to search and found NO information at all; perhaps I'm just
missing the glaringly obvious.

There used to be a Table AutoFormat feature that applied a
pre-defined set of formatting to a table. When you used it, it set
various Properties of the Table Object (AutoFormatType,
ApplyStyleHeadingRos, etc.) which could be referenced in VBA. It may
not have been perfect but it did a job and you more or less knew
where you stood with it. The same feature still exists in Word 2003
(albeit slightly hidden) and still appears to do the same; it doesn't
interact with Table Styles at all.

In Word 2003 (and XP I suppose but I tested in 2K3) there are Table
Styles. There is still a "Table AutoFormat" menu option but it runs
the TableAutoFormatStyle Dialog (which, like the old version, has a
Title of "Table AutoFormat"). The only effect this feature has on the
old Table Properties is that, when you apply a (new format) Style,
the AutoFormatType is set to a value of 1 (wdTableFormatSimple1), and
the .ApplyStyleHeadingRows, etc. properties are set according to the
boxes checked (and acted upon) in the dialog. If you record this
action you will get something along the lines of the following code:

With Selection.Tables(1)
.Style = "Table Grid 4"
.ApplyStyleHeadingRows = True
.ApplyStyleLastRow = True
.ApplyStyleFirstColumn = True
.ApplyStyleLastColumn = False
End With

which is exactly the same as the code example in the Help files. This
code, however, does not carry out the action carried out by the
dialog.

If, after doing this, you invoke the old AutoFormat Dialog it shows
the Format as being "Simple 1" along with whatever special formats
you previously applied to the Style. If you go one step further and
actually apply an AutoFormat it does it 'correctly' in as much as the
format is applied to the Table, but it does it by applying the
formatting on top of the existing Style so the Table retains the
Style but no longer has the characteristics of the Style. If you
then return to the new dialog it shows the Table as being in the
Style previously set in the new dialog but with the various .Apply...
properties reflecting the action taken in the old dialog.

All this might be no more than a bit of light entertainment, but the
real problem comes when you try to work with the table format in
code. It seems nigh impossible to determine, for sure, what formats a
table actually has. If the AutoFormatType is not 1 then it (probably)
correctly reflects the table and this will (probably) be true for
documents created in Word 2000. If the AutoFormatType is 1 and the
table has a non-default style then you can (again probably) infer
that the table has been formatted in XP or 2003 and the Style is the
one which has been used, but it all seems a bit hit and miss.

Is there something obvious I'm not seeing here?

Not being a big fan of pre-defined formats (I always format my table
manually, I never apply an auto format), I am not all that familiar with
Auto-Format.
OTOH, I am very familiar with styles, so when table styles were introduced
I
tried to use them, and then gave up as they are at best a good idea that
went wrong. I cannot get them to work reliably, they conflict with
paragraph
styles and the Normal style seems to have some veto power on character
formatting that drove me insane. If you use a table style, then manually
format some of the content before copying/pasting the table, you often
lose
that manual formatting in the target destination after having pasted the
table. AFAIAC, table styles are a mess.

Until I hear otherwise, I do not use table styles anymore. I use the
default
Table Grid style, and in some cases, I even change the template to Table
Normal as this style even has less of an impact on manual formatting,
especially when doing Copy/Paste jobs.

So, if I want to format a table through VBA, I do it the old fashion way.
I
set the borders and size with explicit statements and use paragraph styles
to format the textual content. This way I am 1000% certain that the table
will end up looking as I want it to be.


--
Salut!
_______________________________________
Jean-Guy Marcil - Word MVP
ISTOO
Word MVP site: http://www.word.mvps.org

Hi Tony,

Your analysis is better than anything I've read anywhere. Probably, =
you'll have to avoid mixing AutoFormat and table styles if you don't =
want an unholy mess. To do MS justice, it's probably not possible to =
introduce something like table styles without creating backward =
compatibility problems. You can blame them, though, on not treating the =
issue in the help files, or not updating the help pages on AutoFormat to =
discourage its use, or for muddying the waters by not renaming "Table =
AutoFormat" to "Table Table styles".

When using table styles (a couple of times), I usually regretted it. =
Apart from the problems Jean-Guy mentioned, all tables sometimes =
suddenly changed their formats because the table style corrupted. And =
since I didn't find any way to fix the corruption, I had to reformat =
dozens and dozens of tables by hand, or revert to an older backup.=20

Since time immemorial (well, Word 6 or so), I've used macros to apply =
formats to tables. I haven't used AutoFormat for tables, since that had =
no advantage over my macro solutions (no automatic update on changes =
without re-applying the AutoFormat respectively re-running the macro), =
but a few disadvantages (mostly: not as flexible). Until I have more =
confidence in table styles, I'll test them on unimportant docs only.

Regards,
Klaus

Thanks, all, for your replies.

The consensus seems to be that Table Styles are a nice idea that simply
isn't yet ready for everyday use. And, reading between the lines a bit, the
reason there is so little information about them anywhere is that they have
been collectively ignored!

It sounds like working with them via the GUI is more trouble than it is
worth, and working with them in code seems to be a non-starter. A shame, as
the idea is a good one.

As I understood it, the situation I was looking at was trying to write code
to pick up what somebody else might have done. The question wasn't one where
you could simply say don't use them, more how would you deal with the case
where somebody else already had used them. It seems that all the styling
characteristics must be individually checked - which I suppose was the case
anyway to do a proper job.

Thanks again for your replies. I shall continue to investigate for it (along
with a completely unrelated issue to do with table placement on the page) has
piqued my interest . Word tables are incredibly flexible and I guess this, in
part, is the reason for them being difficult to work with in code.

Best Regards,
Tony Jollans


"Klaus Linke" wrote:

Hi Tony,

Your analysis is better than anything I've read anywhere. Probably, you'll have to avoid mixing AutoFormat and table styles if you don't want an unholy mess. To do MS justice, it's probably not possible to introduce something like table styles without creating backward compatibility problems. You can blame them, though, on not treating the issue in the help files, or not updating the help pages on AutoFormat to discourage its use, or for muddying the waters by not renaming "Table AutoFormat" to "Table Table styles".

When using table styles (a couple of times), I usually regretted it. Apart from the problems Jean-Guy mentioned, all tables sometimes suddenly changed their formats because the table style corrupted. And since I didn't find any way to fix the corruption, I had to reformat dozens and dozens of tables by hand, or revert to an older backup.

Since time immemorial (well, Word 6 or so), I've used macros to apply formats to tables. I haven't used AutoFormat for tables, since that had no advantage over my macro solutions (no automatic update on changes without re-applying the AutoFormat respectively re-running the macro), but a few disadvantages (mostly: not as flexible). Until I have more confidence in table styles, I'll test them on unimportant docs only.

Regards,
Klaus

Table AutoFormat sets some properties of the Table Object.

Applying a Table Style sets some properties of the TableStyle object.
It also sets a few properties of the Table Object, which I guess is
mildly surprising.

Applying an AutoFormat on top of a Table Style leaves the table
looking like the direct formatting but still having the style
underneath, just like applying direct formatting to a paragraph on top
of a paragraph style leaves the paragraph looking like the direct
formatting, but still having the style underneath.

The Macro Recorder produces bad code for setting a table style; well,
that's not the only bug in the macro recorder.

None of this seems too surprising. What am I missing here?

Bob S


On Wed, 23 Feb 2005 10:15:08 -0800, Tony Jollans
wrote:

In the course of trying to help someone on another forum, I have been looking
at Table AutoFormats vs Table Styles and there seem to be some aspects that
don't work properly. I have searched everywhere I know to search and found NO
information at all; perhaps I'm just missing the glaringly obvious.

There used to be a Table AutoFormat feature that applied a pre-defined set
of formatting to a table. When you used it, it set various Properties of the
Table Object (AutoFormatType, ApplyStyleHeadingRos, etc.) which could be
referenced in VBA. It may not have been perfect but it did a job and you more
or less knew where you stood with it. The same feature still exists in Word
2003 (albeit slightly hidden) and still appears to do the same; it doesn't
interact with Table Styles at all.

In Word 2003 (and XP I suppose but I tested in 2K3) there are Table Styles.
There is still a "Table AutoFormat" menu option but it runs the
TableAutoFormatStyle Dialog (which, like the old version, has a Title of
"Table AutoFormat"). The only effect this feature has on the old Table
Properties is that, when you apply a (new format) Style, the AutoFormatType
is set to a value of 1 (wdTableFormatSimple1), and the
.ApplyStyleHeadingRows, etc. properties are set according to the boxes
checked (and acted upon) in the dialog. If you record this action you will
get something along the lines of the following code:

With Selection.Tables(1)
.Style = "Table Grid 4"
.ApplyStyleHeadingRows = True
.ApplyStyleLastRow = True
.ApplyStyleFirstColumn = True
.ApplyStyleLastColumn = False
End With

which is exactly the same as the code example in the Help files. This code,
however, does not carry out the action carried out by the dialog.

If, after doing this, you invoke the old AutoFormat Dialog it shows the
Format as being "Simple 1" along with whatever special formats you previously
applied to the Style. If you go one step further and actually apply an
AutoFormat it does it 'correctly' in as much as the format is applied to the
Table, but it does it by applying the formatting on top of the existing Style
so the Table retains the Style but no longer has the characteristics of the
Style. If you then return to the new dialog it shows the Table as being in
the Style previously set in the new dialog but with the various .Apply...
properties reflecting the action taken in the old dialog.

All this might be no more than a bit of light entertainment, but the real
problem comes when you try to work with the table format in code. It seems
nigh impossible to determine, for sure, what formats a table actually has. If
the AutoFormatType is not 1 then it (probably) correctly reflects the table
and this will (probably) be true for documents created in Word 2000. If the
AutoFormatType is 1 and the table has a non-default style then you can (again
probably) infer that the table has been formatted in XP or 2003 and the Style
is the one which has been used, but it all seems a bit hit and miss.

Is there something obvious I'm not seeing here?