Microsoft Word Execute Find

This Microsoft Word Applescript has recently returned false or crashes Microsoft Word when it is run in a long applescript.

tell application "Microsoft Word"
		set theFind to find object of selection
-->find id «data iWio00638A0080600000» of selection
		tell theFind
			clear formatting
-->clear formatting find id «data iWio00638A0080600000» of selection
			set forward to true
-->set forward of find id «data iWio00638A0080600000» of selection to true
			set wrap to true
-->set wrap of find id «data iWio00638A0080600000» of selection to true
			set content to ContentToFind
-->set content of find id «data iWio00638A0080600000» of selection to "Evaluation Date"
		end tell
		set theFind to find object of selection
-->find id «data iWio00638A0080600000» of selection
		set execute_find to execute find theFind
-->execute find find id «data iWio00638A0080600000» of selection
-->false
end

The execute find applescript function has worked in the past, in the same script, returning true, and without crashing the Word application.
The identical execute find applescript function currently returns true when run in a short Applescript and does not crash the Word application
The find function also currently works in Microsoft Word’s application Find Dialog Window and returns a selected text.

  1. Is it possible that the length of an applescript causes some disruption in either Applescript’s or Word’s engines, leading to a false response rather than an otherwise true response, or to crashing the target application?
  2. If so, how do I resolve this problem?

Model: MacBook Pro
AppleScript: 2.5
Browser: Safari 600.5.17
Word: 16.15
Operating System: Mac OS X (10.12.6 beta 6)

When something works in a short Applescript but doesn’t work in a long one, the first thing I do to troubleshoot is start introducing delays in the script. This is an annoying solution, but often fixes these problems, in my experience. Although I have no experience with scripting Word.

While “delay [time]” is the easiest way to introduce delays, a looped check to insure a task has been completed is both less time-wasting and more reliable, if there’s any way you can implement some of those.

For example, when I’m UI scripting, I do things like this:


[tell block here]
[command that opens a window here]
set repeatCount to 0
			repeat
				set repeatCount to repeatCount + 1
				if not (exists (first window whose description is "dialog")) then exit repeat
				delay 0.1
				if repeatCount > 50 then
					display dialog "[some error text here]" buttons {"Cancel"} default button "Cancel"
				end if
			end repeat
[end tell]

A delay always wastes time, and can still fail if the operation takes an unusually long amount of time. This waits to be sure the application is caught up without wasting any additional time, and it never fails.

In yours you could maybe put in some repeat loops to do things like, for example, check to see if “wrap” returns true on the text and only proceed after it does. Check the counter, maybe you’ll find that it never iterates a single time and once you set “wrap” to true, it instantly, reliably returns true. So the check loop on that particular command is worthless. But I’m guessing that something in your script occasionally causes an application delay that further script commands overrun, and you need to give it time to catch up in one way or another.

You can start testing that theory by simply adding a few fairly long “delay” lines, and if doing that makes the script complete reliably, then start going back through and trying to figure out which delays are actually needed, how long they actually need to be, or replacing delays with test loops to be sure the program is really caught up.

Also, warning: if you’re on Yosemite, “delay” in Applescript is buggy.

The real questions are.

  • When you run the older shorter script, does it run stable again?
  • Did you update Office?
  • Did you upgraded to an newer macOS in the mean time?

I was assuming ceteris paribus conditions for comparing functionality of the two, but maybe I shouldn’t assume.

I have experienced this - never in pure Applescript functionality, but frequently in UI scripting, and occasionally in application “tell” statements, I’ve had bits of codes that each perform their independent task flawlessly, but once assembled, work intermittently, due to the application sometimes attempting to perform steps before prior steps have completed.

When it comes to UI, you tell the window server (your screen) what to do, like most server processes in macOS. The window server will accept the request but will complete the task on its own terms using its own timetable. There is nothing wrong with AppleScript or AppleEvents here it is just how the window server is designed. So when UI scripting involves dynamic UI elements it could be required to use delays between commands.