"It's not a bug, it's a feature." That was a button distributed at the first WordBasic conference. You call it a feature. So, I'm sure, does MS.
Nonesense. It's a bug.
<hr>Your problem is that the first character of your Heading 3 paragraph, and maybe other characters within the paragraph, are assigned as hidden<hr>
Not so. The first character of my heading 3 paragraph is not hidden. They are *reported* as hidden when showhidden=false by Word, but they are not hidden by their underlying style definition. The insertion point angles to the right to tell the user visually that there is hidden text in the previous paragraph. But it is not actually IN a stream paragraph of hidden, There is no reason -- by design -- that this should also report that the letter "H" -- in the case of the example text -- possesses the hidden attibute. It doesn't. And it isn't style heading 1 or heading 2. It is heading 3.
<hr>Add a space at the end of your heading 2 paragraph and make it non-hidden, and then select the heading 3 paragraph abd make it non-hidden.
Assuming this kludge worked, it would only demonstrate that the handling of a document containing both hidden and non-hidden styles has been poorly designed (or is bug-ridden) It violates the larger design of template/styles and is inconsistent at best.
But it doesn't work in my test. Adding non-hidden to the end of heading 2 manually does nothing to return the proper style name when my original test macro is run. It does misalign the paragraphs visually when hidden is not display. The whole point of styles is that I don't need to do any manual formatting, any extra carriage returns.
(If you are seeing direct formatting of either hidden or non-hidden in the test document, this is residual effect of previous HideAndSeek tests -- do RestCharacter to the entire document to return it to the underlying style definitions and you'll find there are no hidden characters in the non-hidden styles.)
The fact that it's a bug is obvious by the contradiction that paragraph(1). text is the text of the visible paragraph. and paragraph(1).style is the wrong style.
For anyone who uses hidden text a lot and for applications that manipulate documents that use hidden text, the "feature" is a bug. And the workaround is for the developer to remember to always query a paragraph's style from within the pargraph (however you get there -- in the stream or by moving the insertion point) NOT from the home position of the paragraph or from the entire paragraph range. They return false info.
The argument is moot. I have found a functional workaround.
<pre>Set aRange = ActiveDocument.Range( _
Start:=ActiveDocument.Paragraphs(i).Range.End - 1, _