Moving from Microsoft Office VBA to AppleScript:
MacTech's Guide to Making the Transition

Page Prev and Page Next buttons at bottom of the page.

April, 2007
Page 41

   ActiveDocument.Bookmarks("myBookmark").Range.Text = "Inserted Text"

translates to:

tell application "Microsoft Word"

     set content of text object of bookmark ¬

          "myBookmark" of active document to "Inserted Text"

end tell

To insert text at an enclosing bookmark (one where you had selected some text to insert your bookmark), and then recreate the bookmark which would otherwise vanish:

Dim bmRange As Range

Set bmRange = ActiveDocument.Bookmarks("myBookmark").Range

bmRange.Text = "Inserted Text"

ActiveDocument.Bookmarks.Add _

Name:="myBookmark", _

Range:=bmRange

translates to:

tell application "Microsoft Word"

     set bmRange to text object of bookmark "myBookmark" of active document

     set content of bmRange to "Inserted Text"

     make new bookmark at active document with properties ¬

          {name:"myBookmark", text object:bmRange}

end tell

However, if you try that, you end up with a "placeholder" (insertion point) bookmark somewhere completely different in the document! This is once again because of AppleScript's (or, rather, the Word implementation's) inability to keep a variable to a dynamic range once it changes. The instant you change the text of the text range of the bookmark, your range bmRange goes up in a puff of smoke.

You can check that: insert

        properties of bmRange

as the second line inside the tell block, just after defining bmRange in the first line and end the script with an end tell right there. You will get an enormous record of dozens upon dozens of properties of this text range.

Then go back and insert the same line just after the original second line inside the block, i.e., just after setting the content of bmRange to "Inserted Text", and end the script there. You would expect to get the same enormous record of properties with the content property changed. Instead you get no result at all – bmRange does not exist any more. So you cannot use it to define the text object of your new bookmark.

Instead, get the start of content of bmRange before you alter it, (which is identical to the start of bookmark of the bookmark: you can verify that if you wish), measure the length (i.e., count) the string you are inserting, and add that number to the start of content result to get the new end of content, and end of bookmark, for the new bookmark. (The start of content is an insertion point whose number is the same as that of the character it comes after – recalling that the first insertion point and start of content in the document is 0, not 1 – so no subtraction of 1 is needed after adding the length of the new text to get the new end of content.)

Use these two numbers as start of bookmark and end of bookmark properties for making your new bookmark. (They also have the advantage that they are intended to be settable, whereas the text object property is marked as read-only.) Here's the script:

tell application "Microsoft Word"

     set bmRange to text object of bookmark "myBookmark" of active document

     set bmStart to bmRange's start of content

     set content of bmRange to "Inserted Text"

     set bmEnd to bmStart + (count "Inserted Text")

     make new bookmark at active document with properties ¬

          {name:"myBookmark", start of bookmark:bmStart, end of bookmark:bmEnd}

end tell

This works perfectly. It has had to be adapted from the straightforward translation from the VBA that we first tried, after checking it and thinking about the cause of the problem (the problem with ranges being non-dynamic in AppleScript). That led to an alternative approach, using some of the many, many properties, classes and commands available. There's almost always a solution.

It should be quite evident by now that although most of the Word Object Model transfers over quite nicely from VBA to AppleScript, there are quite a number of differences in how VBA and AppleScript work – both in trying to shape the syntax into effective statements, but also sometimes in how (near-)equivalences had to be implemented by the Word developers too, so that a certain degree of working things out, and working around unexpected snags, is part of the process of converting your macros.

That is why I have tried to explain in some detail the why as well as the how, since you will undoubtedly hit other issues in other parts of Word's vocabulary and will need to understand the problems. If you have a sense for why things work as they do, you will undoubtedly also find the solutions.