OK, so the values of the WdBuiltinStyle Enumeration actually correspond
to the index numbers of the built-in styles in the Style collection...
Thanks, that's very helpful!
I'll just describe exactly what is really happening here so that you don't
get tripped up by it in future.
Word's built-on styles such as Heading 3 have names which vary between
different language versions of Word. But whichever version of Word you are
using, the Heading 3 style is still recognised as being the built-in style
even though it can be called something different.
The way this works is that the built-in styles each have their own fixed
numerical position within the Styles collection, represented by the values
in the WdBuiltinStyle enum. So wdStyleHeading3 is -4 in all language
versions of Word.
The other part of the magic of this is something called default properties.
The default property of a Style object is its NameLocal property. If you
look in the Object Browser by pressing F2 in the VBA editor, and search for
the Style object, you will be able to see the list of its properties. You
will see that there is a little sky blue dot in the icon for the NameLocal
property.
Now, the fact that NameLocal is a default property means that when you
compare two objects, what is usually happening is that you are in fact
comparing the values of their default properties.
So, to take Dave Lett's example
If Selection.Paragraphs(1).Style = _
ActiveDocument.Styles(wdStyleHeading3) Then
Debug.Print True
End If
What is actually happening is this
If Selection.Paragraphs(1).Style.NameLocal = _
ActiveDocument.Styles(wdStyleHeading3).NameLocal Then
Debug.Print True
End If
In both cases, you are comparing the strings of the NameLocal property.
Generally (though I am by no means entirely consistent about his in my own
code) I prefer to avoid depending on the use of default properties. There
are three reasons for this.
1. When moving from one version of Word to the next, the code becomes
dependent on Microsoft not changing default properties. Microsoft has been
reasonably good about keeping this consistent, but it is better not to
depend on this too heavily.
2. Sometimes leaving out the explicit property name can be a bit confusing
when trying to debug the code - it can be unclear whether you are referring
to the object or its default property.
3. At some stage your VBA code might have to be migrated to VSTO or an
embedded version of VB.NET that may eventually be introduced into Office.
VB.NET does not support default properties the way VBA does. There is no
automated code converter from VBA to VB.NET at present and I mistrust the
ability of any future automated code converter to do the job properly. Using
property names explicitly will reduce the pain of that eventual migration if
and when it proves necessary.
