none
Why Does Retrieving the Range::get_Orientation Property Turn Off the Bold/Italic/etc???? RRS feed

  • Question

  • Hi Word Forum Experts!!!

    I would appreciate if you'd read this article and provide any possible insights on a very weird bug that seems to have existed in Word Automation since the beginning.....

    Here's a small VBA program that I typed in to show this issue....

    Public Sub GetOrientation()

    Selection.TypeText Text:="Hello there sweetie"

    Set objRange = ActiveDocument.Range(Start:=0, End:=Selection.End)

    Selection.Font.Bold = True

    MyOrientation = objRange.Orientation

    End Sub

    As you run this little subroutine in the VBA debugger, watch the Bold button on the ribbon.  When you execute the line "Selection.Font.Bold" the Bold button turns on.  When you execute the line MyOrientation = objRange.Orientation it turns off!  This seems to be a bug in Word!  Getting the Orientation of a Range should not mess around with font bolding, italicizing etc. 

    This problem is evident for any font property that we turn on or off (bold, italic, strikethrough etc).  When you try to retrieve the Orientation, that property turns off!

    The application that I'm working on tries to passively reading the Word document.  What we do in our real code is basically create a Range object which covers a line of text on the screen.  Then, we try to get the Orientation of the Range.  The Active Document's Selection property should be a "bystander" in this retrieval of the Range's Orientation!  Instead, it seems that Word (I've tested this all the way from Word XP to Word 2010), seems to backup the Selection over the previously typed text (in this case "Hello Sweetie") which TURNS OFF THE BOLD button.!!!! 

    This problem occurs whether you program the Word Object Model in-proc or out-of-proc, in VBA, VB.NET, or VC++.  If you collapse the Selection (which we cannot do since we're a "passive reader of the screen" and we don't want to screw up what the user has selected) between the penultimate and last lines of the macro, the problem does not occur

    Does anyone have any explanation as to why this occurs and any workarounds?  Thanks for any light that you can shed on this very weird behavior of Word!


    Fred




    • Edited by FEINSTEI Tuesday, March 22, 2011 7:18 PM
    Monday, March 21, 2011 9:13 PM

Answers

  • Hi Fred,

    But the document isn't being changed. If you watch what happens, nothing in the document is being changed when your 'MyOrientation = objRange.Orientation' code runs. All that happens is that the bold attribute is deselected. I'll grant that this could have implications for whatever you want to do next, but this could be overcome by simply applying the bold attribute after retrieving the orientation. Alternatively, since you want to return the orientation for a range that includes the selection then, unless you're concerned that there might be a mix of orientations, you could simply use 'MyOrientation = .Orientation'.


    Cheers
    Paul Edstein
    [MS MVP - Word]
    • Marked as answer by FEINSTEI Wednesday, March 23, 2011 1:46 PM
    Wednesday, March 23, 2011 1:48 AM

All replies

  • Hi Fred,

    If you comment out the line 'MyOrientation = objRange.Orientation' and run the macro in an empty document, you'll find that the only thing that get's bolded is the paragraph break. If, instead of running the 'MyOrientation = objRange.Orientation' line you run 'Selection.Collapse', you'll see that too toggles off the Bold button. However, nothing has changed in the document's contents. It seems, therefore, that all the 'MyOrientation = objRange.Orientation' line is doing in this regard is collapsing the selection.


    Cheers
    Paul Edstein
    [MS MVP - Word]
    Tuesday, March 22, 2011 9:03 AM
  • Hi Paul,

      I think that you misunderstood my point.  My desire is just to passively read the state of the Orientation without collapsing or changing the Selection in any way.  It is not my desire to bold anything.  What I'm doing is monitoring changes to the state of Word, specifically, the state of the Orientation as the user is typing.   

    My point is that reading the Range::Orientation property should NOT change the document in any way.  In fact, reading ANY property should not change the document in any way!  That's the bug in Word. 


    Fred
    Tuesday, March 22, 2011 12:27 PM
  • And here's yet another example of a bug in Word's Object Model.  Trying to get the HightlightColorIndex exhibits the same behavior!

    Just paste this little program into WordBASIC, debug it line-by-line, and you'll see the bold button turn off when we try to retrieve the Range's HighlightColorIndex!

     

    Public Sub HighlightColorIndex()
    Selection.TypeText Text:="JustATextString"
    Set objRange = ActiveDocument.Range(Start:=0, End:=Selection.End)
    Selection.Font.Bold = True ' turns on the bold button
    MyHighlightColor = objRange.HighlightColorIndex  ' BUG BUG turns off the bold button!
    End Sub


    Fred
    Tuesday, March 22, 2011 6:50 PM
  • Hi Fred,

    But the document isn't being changed. If you watch what happens, nothing in the document is being changed when your 'MyOrientation = objRange.Orientation' code runs. All that happens is that the bold attribute is deselected. I'll grant that this could have implications for whatever you want to do next, but this could be overcome by simply applying the bold attribute after retrieving the orientation. Alternatively, since you want to return the orientation for a range that includes the selection then, unless you're concerned that there might be a mix of orientations, you could simply use 'MyOrientation = .Orientation'.


    Cheers
    Paul Edstein
    [MS MVP - Word]
    • Marked as answer by FEINSTEI Wednesday, March 23, 2011 1:46 PM
    Wednesday, March 23, 2011 1:48 AM
  • Hi again Paul,

       Your suggestion to just get the orientation or the highlight color (colour?) index at the Selection is a helpful one since this doesn't mess up the font properties by Word's internal changing of its property focus to match the Range.  I think that this is a good workaround for this issue.  Thanks.


    Fred
    • Marked as answer by FEINSTEI Wednesday, March 23, 2011 1:45 PM
    • Unmarked as answer by FEINSTEI Wednesday, March 23, 2011 1:46 PM
    Wednesday, March 23, 2011 1:45 PM