It must be one of the most asked questions about macros - why has it not been addressed in the macro language after all these years?

D PaulDalton,

Glad I could help and I understand your comments and concerns. 

Unfortunately, I don't know if your suggestions will ever get any traction even if they made it to the "right person.  In line with what Jay and Peter have said, my experience is that VBA becomes less and less complete as Word progresses rather than more and more complete.  For example, everything that you could do as a user with a drawing or shape object in Word 2003, you could do with VBA.  With the new graphics engine introduced with Word 2010, there are many things that a user can do that now cannot be done with VBA.  Most of the things that you can do with those graphics are not even recorded.  I suspect that the recorder will go away before it becomes anything like you envision.  Still, it is a good and valid vision.

Good luck.

I have a few observations, and that's probably about all I'll be able to contribute here.

In order to get much further with getting Microsoft to do this, you'll need to get your idea onto their agenda. While it's possible that ideas posted here sometimes get some attention from them, you can't guarantee it: you aren't really dealing with Microsoft people (it's mostly volunteers), and certainly not the Microsoft product group people, in here. So you either need to know someone, or find a proxy (either someone close or perhaps an influential corporate that can see the value of the idea). As for timing, I don't know what their product cycle looks like now, either - it could well be changing rapidly as their Office 365 subscription service develops. But if it's the old cycle, I would guess they already have the outline if not most of the details for the version after 2013 and may be thinking about ideas after that. Also, I would be very surprised if they did not want to be absolutely sure of their ground as far as Intellectual Property is concerned.

On the technical front, the biggest technical questions for me are "what can be done in the 'DO' part of the feature?" (i.e. the one you described a few messages back)

If it's "execution of an arbitrary macro", then it can do anything VBA can do, form "something sensible" to "accidentally trash every file on the system." It can also contain infinite loops, code that results in untrappable errors - at least not trappable by VBA - and doubtless other things I haven't even thought about that may result in dismay for the user.

As long as the user is willing to take responsibility for their part of the code, I don't see any technical showstoppers*.* But that doesn't mean that such problems won't turn up.

From a support perspective though, having a half-and-half feature like that is a bit of a liability, to say the least.

Going to a slightly more detailed level, when I read your earlier messages, I got the impression that you were keen to avoid the more techie stuff involving selections, ranges etc. The trouble is that if the user still has to write VBA, e.g. to find something then move a few words to the right or whatever, they still have to understand that stuff. What's more, in the general case some code will function in (say) a paragraph in the main body of the document, but fail in a footer (say). In other words, in many cases the user would need to understand even more about their code.

When I first read your question, I had a slightly different idea as to what you were driving at. To me, how you avoid dealing with "allowing any piece of VBA" is to try to identify a small but potent set of things the user might want to do (obviously reducing the generality obtainable in VBA) and allow them to do those things and nothing else. That's one of the reasons I suggested that a change to the recorder might be needed - you'd only be able to record the things that the feature is designed to allow. Then the feature takes responsibility for making all that stuff happen. How to do that technically is a detail, but perhaps specify that the DO macro only contains calls to a number of predefined subs/functions that have been designed to behave well within the overall structure of the feature. Or define a completely new, small, non-VBA language and some VBA to interpret it.

Finally, I know we have been taking about Word and VBA. But really, we're talking about providing a set of features for repetitive processing. The Web App version of Word doesn't have any of that stuff, and perhaps it is intended that it never will. But because it doesn't have VBA, it would I think benefit far more from a feature to let its users do something like "do this in every paragraph that begins with 'Jack Robinson'"