none
"Fields" getting messed up in Word 2007 RRS feed

  • Question

  • Hi,

    I am fairly new to Word fields, and I have just set up a large document to use them.  However, Word 2007 is messing up lots of my fields, and I can't figure out why.  For instance, if I have the text

    { IF { vvInternal } = 1 "A" "B" }

    And I have the bookmark vvInternal set to 1.  This works fine and evaluates to A.  But later on, I find that the same snippet doesn't work right.  Instead it evaluates to B.  So I think maybe I've written something wrong, so I copy that same text right below it (Ctrl-C, Ctrl-V), so I have two lines with the exact same text.  Then I re-apply both fields (F9), and then the first statement still evaluates to A (bad) while the newly copied statement evaluates to B (good).  (Note that the real text is not "A" and "B", but some real short text in my document.)

    I can't figure out why Word is messing up the original statement - it seems like a bug.  It seems to be prevalent after I save the file and reopen it, although I'm not positive it's related to that.

    Also, when I copy the text above, "{ vvInternal }" sometimes turns into "{ vvInternal1 }" in the copied version (with an extra number 1 at the end), although the copied version still seems to work properly.

    Also, after I've re-opened the document, sometimes the original snippet above shows up without all of its close-brackets - it might loook like this instead:

    { IF { vvInternal = 1 "A" "B"

    Does anyone know what is going on with Word?  Any suggestion appreciated!




    Monday, April 25, 2011 3:30 AM

Answers

  • Hi Eliot,

     

    There are a couple of things happening in this document that contributed to its problem. The first is there are two bookmarks that encompass the vvInternal setting. One is labeled vvInternal, the other is OLE_LINK. The other problem area is Tracked Changes.

     

    The unaccepted changes involved the deletion of empty paragraph marks and accepting them brought a Section Break (Continuous) to an anchor position of the paragraph mark that both the vvInternal bookmark and the OLE_LINK also surrounded.

     

    Moving the continuous section break to a line of its own partially fixed the problem but it was not fully fixed until I redefined the bookmark of vvInterna.  l started the bookmark at the same location it previously had but I added the paragraph mark as part of its span.

     

    Previously the ending location of the vvInternal bookmark was at the position just prior to this paragraph mark and the ending position of the OLE_LINK bookmark was in the position immediately following this same paragraph mark.  Moving the ending location of the vvInternal bookmark to be the same as the OLE-LINK bookmark, corrected the problem.

     

    I believe too much was going on at this one lone paragraph mark and that confusion ensued.


    Regards, Rich
    Monday, April 25, 2011 7:29 PM
  • PS - I should probably try to clarify what I obseved when track changes were not accepted and subsequently accepted.

    When not accepted, everything appeared fine in the document. i.e. the continuous section break was three or four lines down the page. Unfortunately, those paragraph marks were actually deleted and visually you could not see that the section break had anchored itself on top of the ending span of the OLE_LINK.

    Once I accepted the changes, I saw the issue being an unclear/potentially undefined ending to the OLE_LINK bookmark.

    So track changes directly was not altering the bookmark field, the section break was, but track changes masked the problem.


    Regards, Rich
    Monday, April 25, 2011 7:51 PM
  • Also, if I have some text inside a field - say { IF { A } = 1 "Print Yes" "Print No" } - is there a way to remove the "field" nature (the outside parentheses), without removing the text inside?  I could copy the inside text and paste it elsewhere, but that would mark it as changed text.


    Hi Eliot,

    Only by switching off 'track changes' while you're doing it. Either that or you could delete the field and start over. If the field is part of a change addition that hasn't been saved, its deletion won't show up as a tracked change.


    Cheers
    Paul Edstein
    [MS MVP - Word]
    Tuesday, April 26, 2011 3:41 AM
  • FYI - An Update:

    Since we determined that Fields don't play well with Track Changes, I changed the entire methodology of my doc.  Originally I was using fields:

    { IF { vvInternal } = 1 "Text A" "Text B" }

    Instead, I re-coded the entire doc to use data that I could parse with a macro:

    [Internal]Text A[/] [~Internal]Text B[/]

    And then I created a macro to make the modifications - for example, here is a snippet for the "Internal" flag:

        ' Internal
        Selection.Find.Execute Replace:=wdReplaceAll
        With Selection.Find
            .Text = "(\[Internal\])(*)(\[/\])"
            .Replacement.Text = ""
            .Wrap = wdFindContinue
            .MatchWildcards = True
        End With
       
        Selection.Find.Execute Replace:=wdReplaceAll
        With Selection.Find
            .Text = "(\[~Internal\])(*)(\[/\])"
            .Replacement.Text = "\2"
            .Wrap = wdFindContinue
            .MatchWildcards = True
        End With

    This is still a little termpermental with change tracking, but overall it is working well, and it does not involve the "hokus pokus" of fields.  Of course, fields can do more advanced things, like real calculations, but it my case, I only needed conditional text, so using text that I can parse with a macro worked fine.  I am happy with this solution.

    Eliot

     

    Wednesday, April 27, 2011 7:32 PM

All replies

  • Hi Eliot

    In my experience, it's always a good idea to include the field name in the field code, rather than counting on Word to "guess" that you mean a bookmark (as opposed to a number of other internal things, such as Word and Windows settings).

    So, does it make any difference if you do this:

    { IF { REF vvInternal } = 1 "A" "B" }

    Also, where are the bookmark and the If field located in the document? In plain text? In a table? (You get the idea).


    Cindy Meister, VSTO/Word MVP
    Monday, April 25, 2011 5:39 AM
    Moderator
  • Hi Eliot,

    Your description sounds rather like you're getting some extraneous content into your fields, perhaps because of double-pasting - especially copying & pasting fields that haven't been updated after their creation (in which case they often disappear, giving the impression there's nothing there). When working with fields, it is often best to toggle the field code display on. via Alt-F9, so that you can see exactly what is in each field when you are copying and pasting. I suggest you do this - you may get a few surprises.


    Cheers
    Paul Edstein
    [MS MVP - Word]
    Monday, April 25, 2011 11:51 AM
  • Cindy,

    I took one of the ofending lines and added "REF" to it as you suggested.  That did not help.

    The problem occurs both in regular text, and in tables.

    I created a one-page example of this showing the line that should work but doesn't.  Could I email it to you?  I'd prefer not to post it here, just in case my doc contains other hidden items.

    Paul,

    Yes, I often toggle the field code using Shift-F9 and it seemed ok earlier.  Even when I toggle the field now to show the raw code, I can see it and it looks ok.  But it's still not evaluating correctly. 

    Eliot


    Monday, April 25, 2011 3:11 PM
  • ok, Here is what I discovered: The problem has something to do with having TRACK CHANGES on.

    With my little example doc, if I accepted all changes, then the previously bad code started working again.

    When I tried this on my large doc, and I accepted the changes in that area, the bad code started working again. 

    And remember in my original post I said in some places the code looks like this (with missing brackets or other mess-ups that were not there in the original code code that I typed in):

    { IF { vvInternal = 1 "A" "B"

    Well, for that code, when I Accept Changes, the entire code snippet disappears, never to be seen again even with Shift-F9 or Alt-F9.  The only way to see it again is to "Undo" the Accept Changes.

     

    So, is there a known bug when using fields with Track Changes on?  I need to track changes in my doc.

    Thanks,

    Eliot

    Monday, April 25, 2011 4:43 PM
  • Hi Eliot,

    How are you updating all of the fields in the document? Do you select each field individually, or select all (Ctrl + A) and then press F9, or are you running a macro with code such as:

    ActiveDocument.Fields.Update

    For diagnosing the problem, do you have all non-printing characters showing in the document? Does the document or it's template have macros that execute automatically and that could be altering something or stepping on the bookmark or field?

    I ask these questions because I tested the If field command linked to a bookmark on 2007 and 2010 (just as you specified) and it did not fail for me.


    Regards, Rich
    Monday, April 25, 2011 5:40 PM
  • Rich,

    I update the fields using either Ctrl-A then F9.  I am not using a macro to update the doc.

    I have tried displying all non-printing characters (Ctrl+*) but that did not indicate any issues.  I am not running other macros.  The bookmark is correct, because if I use it later (on uncorrupted text), it works fine.

    I am happy to email you or anyone else the example one-page Word docx that shows the problem.  (I don't see how to upload it to this site.)  In this doc, the field is not getting properly parsed.  But if I Accept All Changes, then the field works again.

    My email is eliotaustin at gmail dot com

    Eliot

    Monday, April 25, 2011 6:09 PM
  • Hi Eliot,

    I've sent you an email that will have my email address so you can send the file to me if you wish.

    However, I think you've already discovered what the issue is ... Track Changes. Not a feature I particularily like because of how it messes up a number of things in complex documents as well as how it degrades system performance.

    I much prefer the Compare document feature. It gives most users the essential "what's changed" info that they need, but without all the headaches and document issues when the tracked changes are never accepted or rejected. 


    Regards, Rich
    Monday, April 25, 2011 6:33 PM
  • Rich,

    I've emailed you the sample doc showing the issue.  I need to use Track Changes in my doc to highlight what has changed, so it's not an option to disable it.  I can understand Track Changes slowing things down (which it does), but I wouldn't expect it to make my fields inoperable.

    Eliot

    Monday, April 25, 2011 7:10 PM
  • Hi Eliot,

     

    There are a couple of things happening in this document that contributed to its problem. The first is there are two bookmarks that encompass the vvInternal setting. One is labeled vvInternal, the other is OLE_LINK. The other problem area is Tracked Changes.

     

    The unaccepted changes involved the deletion of empty paragraph marks and accepting them brought a Section Break (Continuous) to an anchor position of the paragraph mark that both the vvInternal bookmark and the OLE_LINK also surrounded.

     

    Moving the continuous section break to a line of its own partially fixed the problem but it was not fully fixed until I redefined the bookmark of vvInterna.  l started the bookmark at the same location it previously had but I added the paragraph mark as part of its span.

     

    Previously the ending location of the vvInternal bookmark was at the position just prior to this paragraph mark and the ending position of the OLE_LINK bookmark was in the position immediately following this same paragraph mark.  Moving the ending location of the vvInternal bookmark to be the same as the OLE-LINK bookmark, corrected the problem.

     

    I believe too much was going on at this one lone paragraph mark and that confusion ensued.


    Regards, Rich
    Monday, April 25, 2011 7:29 PM
  • PS - I should probably try to clarify what I obseved when track changes were not accepted and subsequently accepted.

    When not accepted, everything appeared fine in the document. i.e. the continuous section break was three or four lines down the page. Unfortunately, those paragraph marks were actually deleted and visually you could not see that the section break had anchored itself on top of the ending span of the OLE_LINK.

    Once I accepted the changes, I saw the issue being an unclear/potentially undefined ending to the OLE_LINK bookmark.

    So track changes directly was not altering the bookmark field, the section break was, but track changes masked the problem.


    Regards, Rich
    Monday, April 25, 2011 7:51 PM
  • OK, so Rich and I had a couple of emails about the example I sent him, and we both believe that "TRACK CHANGES" IS SOMEHOW CORRUPTING THE FIELDS, so that some of them stop working properly.  If you Accept All Changes in the doc, then all the fields work again. 

    Is this a known bug in Word that Fields get corrupted when using Track Changes?  Have others seen this?  I can send my simple 1-page doc if anyone wants to take a look. 

    I need to use Track Changes, so unless I can find a workaround to this, I cannot use Fields, which is unfortunate.

    Thanks,

    Eliot

    p.s. And Thanks Rich for your other comments.


    Tuesday, April 26, 2011 1:49 AM
  • Hi Eliot,

    From the foregoing discussion, it seems the real issue is one of your bookmarks including ranges that were part of a tracked deleted range. To avoid that, you might need to ensure that all changes are displayed when you create the bookmarks and, if you add/delete anything in the bookmarked range (which is quite easy to do inadvertantly), you need to redefine the bookmark's range accordingly to exclude those changes.

    Inserting, deleting and updating fields can also result in additional tracked changes. The following macro clears those trackings:

    Sub AcceptTrackedFields()
    Dim oRng As Range, oFld As Field
    With ActiveDocument
      ' Loop through all range objects and accept tracked changes on fields
      For Each oRng In .StoryRanges
        Do
          For Each oFld In oRng.Fields
            oFld.Select
            Selection.Range.Revisions.AcceptAll
          Next
          Set oRng = oRng.NextStoryRange
        Loop Until oRng Is Nothing
      Next
    End With
    End Sub


    Cheers
    Paul Edstein
    [MS MVP - Word]

    Tuesday, April 26, 2011 2:09 AM
  • Eliot,

     

    Following up on my previous notes and emails …

     

    The issue is tracked changes and I think it occurs when the bookmark value is changed but all fields are not updated.

     

    The bookmarked value is properly stored and referenced by the assigned bookmark name. Thus if the bookmark value is 1, even after revising with tracked changes, Word knows the proper current value.

     

    However that is not what occurs in the True/False field. The referenced bookmark is interpreted as the actual displayed value, which in the case of tracked changes being on, might be something like 21 with a delete mark over the 2.  Taken literally, a bookmark value of 1 does not equal the 21(with slashed mark over the 2) and thus you get inconsistent results.

     

    That’s the most I can figure out right now about what’s going on.


    Regards, Rich
    Tuesday, April 26, 2011 2:44 AM
  • ok, I will try a few more experiments tomorrow.

    Also, if I have some text inside a field - say { IF { A } = 1 "Print Yes" "Print No" } - is there a way to remove the "field" nature (the outside parentheses), without removing the text inside?  I could copy the inside text and paste it elsewhere, but that would mark it as changed text.

    Tuesday, April 26, 2011 3:22 AM
  • Also, if I have some text inside a field - say { IF { A } = 1 "Print Yes" "Print No" } - is there a way to remove the "field" nature (the outside parentheses), without removing the text inside?  I could copy the inside text and paste it elsewhere, but that would mark it as changed text.


    Hi Eliot,

    Only by switching off 'track changes' while you're doing it. Either that or you could delete the field and start over. If the field is part of a change addition that hasn't been saved, its deletion won't show up as a tracked change.


    Cheers
    Paul Edstein
    [MS MVP - Word]
    Tuesday, April 26, 2011 3:41 AM
  • Paul,

     

    I think you are right.  The Change Tracking is corrupting the fields. 

     

    Here was a simple example.  With Track Changes on, I start with

       { IF “1”=1 “Textme1” “Textme2” }

    And Accept all changes to the above line.

    Hitting F9, Shift+F9 correctly gives

      Textme1

    Then going back to the field view with the brackets, and removing the “me” gives.

       { IF “1”=1 “Text1” “Text2” }

    But F9, Shift+F9 still gives

      Textme1

    Instead of the expected “Text1”.

    The only way to get the expected “Text1” is to Accept Changes in that line.

     

    Accepting changes seems to work in my limited test but is not ideal because I still want to track changes even inside the fields.

     

    Does that make sense and is expected? 

     

    Eliot

     

    Tuesday, April 26, 2011 5:25 PM
  • Hi Eliot,

    If need to make changes that involve fields, the only way I can suggest doing so with a semblance of reliability is to delete the whole field and insert a new one with the desired change. Cut & paste could be used, with the pasted version being edited.


    Cheers
    Paul Edstein
    [MS MVP - Word]
    Tuesday, April 26, 2011 8:47 PM
  • FYI - An Update:

    Since we determined that Fields don't play well with Track Changes, I changed the entire methodology of my doc.  Originally I was using fields:

    { IF { vvInternal } = 1 "Text A" "Text B" }

    Instead, I re-coded the entire doc to use data that I could parse with a macro:

    [Internal]Text A[/] [~Internal]Text B[/]

    And then I created a macro to make the modifications - for example, here is a snippet for the "Internal" flag:

        ' Internal
        Selection.Find.Execute Replace:=wdReplaceAll
        With Selection.Find
            .Text = "(\[Internal\])(*)(\[/\])"
            .Replacement.Text = ""
            .Wrap = wdFindContinue
            .MatchWildcards = True
        End With
       
        Selection.Find.Execute Replace:=wdReplaceAll
        With Selection.Find
            .Text = "(\[~Internal\])(*)(\[/\])"
            .Replacement.Text = "\2"
            .Wrap = wdFindContinue
            .MatchWildcards = True
        End With

    This is still a little termpermental with change tracking, but overall it is working well, and it does not involve the "hokus pokus" of fields.  Of course, fields can do more advanced things, like real calculations, but it my case, I only needed conditional text, so using text that I can parse with a macro worked fine.  I am happy with this solution.

    Eliot

     

    Wednesday, April 27, 2011 7:32 PM
  • Hi Eliot,

    Glad to see it worked out for you. :-)


    Regards, Rich
    Wednesday, April 27, 2011 7:43 PM