Storing your macros in add-ins (.xlam) has many advantages over personal.xlsm and similar document locations.

One disadvantage is that an Add-in macro is not accessible through the macros dialogue.

The community recommends assigning shortcuts for easy access. I did that and went a couple of steps further using VBE extensibility to

depending on scope

public procedures on your end users’ computer to whom you distribute your Add-in

and also non-private on the developer machine

list your modules alphabetically

list your macros alphabetically under your modules

find pick a free (within Excel – short of windows-wide shortcuts – In my current work environment, I am unable run tools that allow you to list these shortcuts) shortcut combination and and assign it to your macro Code

If confronted with a sizable Testing Anywhere test script codebase which has been marginally, but not substantially enhanced/cleaned up in several years while producing a barrage of automation errors daily,

you may find that the run suite errors that Testing Anywhere logs automatically in its rlgx files are your best data source for monitoring and designing a plan of attack:

Any oft-failing scripts should be put last during the daily run? how about length script needs to run?

Any failing script parts could be modularized and during the daily run?

any oft-failing scripts? E.g. here the top 8% of failing scripts have almost 30% of the errors.

Any oft-failing approaches that might benefit from refactoring? Starting with which scripts? Main actions, then sub-actions:

etc.

Then this PowerShell script may help which

extracts the non binary <runlog> items out of the binary rlgx files,

and merges them into a single file

which it wraps with an XML declaration and root level node that Excel can work with.

At this point, I cannot get the add-in to work only in Word 2010. Even if I lower Macro security and allow programmatic access to the VBA project, when trying to launch the add-in from the ribbon, Word 2013 complains: “The macro cannot be found or has been disabled due to your macro security settings”:.

The automation is only as good as your underlying search/replace operations. (Hint: “Some people, when confronted with a problem, think ‘I know, I’ll use regular expressions.’ Now they have two problems.”)

I think I will refrain from search/replace during “Tracking changes” – as in the video – , and rather use “Compare documents” after the replace operations – too many quirks otherwise…