Intercepting Word Commands? (Word 2K/XP)

Topic

New Reply

I have tried the approaches in some previous posts to intercept commands in Word (by means of creating macros with the same name) and found something strange. Some commands are intercepted perfectly but others are not intercepeted. One interesting thing is that the DrawInsertTextBox can be intercepted while DrawInsertOval cannot. I am wonder whether it is some omission of Microsoft. Others that I think should be intercepted but are not include DrawGroup, FillColor, etc.

I need to intercept most of the Word command in my project. Any hints would appreciated.

Reply | Quote

Replies

DrawTextBox (I don’t know DrawInsertTextBox) is an internal Word command (the equivalent of Insert | text Box); it can be intercepted. There is no separate Word command for ovals, so there is nothing to intercept. You can download a list of Word for Windows commands, and their descriptions, default shortcuts and menu assignments from the Word MVP site.

Reply | Quote

Hi, Hans. Thanks for you quick reply.

I have read that command list, but still have something that I cannot understand. For example, the command DrawGroup is in the list but cannot be intercepted by creating a macro with the same name. Are all the commands in the list interceptable or do I need other techniques to do so?

Regards

Reply | Quote

Frankly, I don’t know. The WordCommands list contains some comments about macros not intercepting actions; I have no extra information.

Reply | Quote

Thanks anyway. At least I can intercept some of them based on your previous posts.

Reply | Quote

Thanks anyway. At least I can intercept some of them based on your previous posts.

Reply | Quote

Frankly, I don’t know. The WordCommands list contains some comments about macros not intercepting actions; I have no extra information.

Reply | Quote

I can interecept DrawGRoup in Word 2003.
The Sub must be Public and must be avaiable in the project or, maybe, in a global template.

Reply | Quote

Hi Howard,

I was unable to intercept DrawGroup in Word 2003 (and it doesn’t show in the list of commands generated by the ListCommands command). Command command command.

What were you doing when you invoked the command and intercepted it?

Reply | Quote

In my Word 2K the command DrawGroup showed up when I executed ListCommands but it does not in my Word XP. However, when I created the macro DrawGroup in Word XP, it automatically put the statement WordBasic.DrawGroup in the sub, which acknowledges that it is an internal command in Word (I think). But neither version works to intercept.

What a strange application! I don’t know what they are thinking about when they designed it.

Reply | Quote

Yeah, I remember being elated to find “Style” listed as a command that could be intercepted — I hoped that meant that I could intercept the application of particular styles. You can even do the Word Commands -> Create on Style, and it gives you:

WordBasic.Style

But that command is useless without an argument, and regardless, once created, I’ve yet to find anyway to show that it’s intercepting anything. Argh.

Reply | Quote

Yeah, I remember being elated to find “Style” listed as a command that could be intercepted — I hoped that meant that I could intercept the application of particular styles. You can even do the Word Commands -> Create on Style, and it gives you:

WordBasic.Style

But that command is useless without an argument, and regardless, once created, I’ve yet to find anyway to show that it’s intercepting anything. Argh.

Reply | Quote

“thinking”?
“designing”?

Maybe we need to add

With Microsoft
    With .Word
        .FixBugs =True
        .LearnHowToDesignSoftware = True
        With SoftwareQualityAssurance
            .LearnHowToDoSQA = True
        End With
    End With
    .AllOfTheAbove = True
    .AndThenSome = True
End With

Dim bug as Word.Bug
For Each bug in Word.Bugs
    bug.fix
Next bug
Set bug = Nothing

Reply | Quote

“thinking”?
“designing”?

Maybe we need to add

With Microsoft
    With .Word
        .FixBugs =True
        .LearnHowToDesignSoftware = True
        With SoftwareQualityAssurance
            .LearnHowToDoSQA = True
        End With
    End With
    .AllOfTheAbove = True
    .AndThenSome = True
End With

Dim bug as Word.Bug
For Each bug in Word.Bugs
    bug.fix
Next bug
Set bug = Nothing

Reply | Quote

In my Word 2K the command DrawGroup showed up when I executed ListCommands but it does not in my Word XP. However, when I created the macro DrawGroup in Word XP, it automatically put the statement WordBasic.DrawGroup in the sub, which acknowledges that it is an internal command in Word (I think). But neither version works to intercept.

What a strange application! I don’t know what they are thinking about when they designed it.

Reply | Quote

Option Explicit

Private Sub TestIntercept()
DrawGroup
End Sub

Public Sub DrawGroup()
Debug.Print “DrawGroup intercepted”
End Sub

Reply | Quote

Maybe a better test is whether you can intercept this:

CommandBars.FindControl(Id:=164).Execute

(Of course, you should be able to intercept it by setting up a class to watch for CommandBar events… some past examples:

Word:	Re: Disabling Email in Word (Office 2000 Word)
PowerPoint:	Re: Autosave everytime i quit power point (2000)
Outlook:	Re: Outlook COM ADD IN (Office XP VBA6)

I think the question is: is there a simpler way in this case?)

Reply | Quote

Using IDs is not a reliable approach.
Ids can change from version to version of Word, I’ve seen it happen.
One could try using the control name instead of the ID.

However, executing the control item directly is unlikely to afect which code iis executed.

Reply | Quote

> One could try using the control name instead of the ID.

Control names seem to change depending on the language of the users menus

StuartR

Reply | Quote

Yes, but one can provide for that within the code.

A number of years ago, MSFT did change at least one ID for a built-in control, don’t recall which.

Reply | Quote

Yes, but one can provide for that within the code.

A number of years ago, MSFT did change at least one ID for a built-in control, don’t recall which.

Reply | Quote

> One could try using the control name instead of the ID.

Control names seem to change depending on the language of the users menus

StuartR

Reply | Quote

Another problem of using caption is that it changes during the running process. For example, the caption of the undo button is “Can’t Undo”. And then it becomes “Undo sth…”. Are there any other ways not so troublesome?

Regards

Reply | Quote

You can program around this by using a Select Case to detect the langusge and the appropriate string to use for the Caption at each stage of processing.

Reply | Quote

Another problem of using caption is that it changes during the running process. For example, the caption of the undo button is “Can’t Undo”. And then it becomes “Undo sth…”. Are there any other ways not so troublesome?

Regards

Reply | Quote

I understand your argument on the first part. That is a risk. But I’m not sure I understand this one:

> However, executing the control item directly is unlikely to afect which code iis executed.

If I execute the ID for File>Save on my computer, the custom code for our document management system (Sub FileSave in a global template) intercepts the action and runs as expected.

Reply | Quote

I think “DrawGroup” is an example of what Howard warned about: a command which changed its Id.

And it wreaks havok with intercepting the command, because Word still uses the old Id in many places.

If you add “DrawGroup” to some toolbar or menu using its real, new Id, it will be intercepted:

Dim a As CommandBarControl
Set a = CommandBars("Menu Bar").Controls.Add(ID:=3454)
' while this would raise an error:
' Set a = CommandBars("Menu Bar").Controls.Add(ID:=164)

There are quite a few drawing commands with changed Ids in Word2002/2003 (DrawBringForward, DrawFlipVertical, …).

I would still use the Ids in my code. If MS messes with them, the code probably won’t work any more anyway.

Another weird thing I found today is that not all built-in commands do the same as the WordBasic commands with the same name (something I found to hold true until today): InsertAnnotation adds a comment in the Reviewing pane, WordBasic.InsertAnnotation in the Comments pane.

Klaus

Reply | Quote

“Another weird thing I found today is that not all built-in commands do the same as the WordBasic commands with the same name (something I found to hold true until today): InsertAnnotation adds a comment in the Reviewing pane, WordBasic.InsertAnnotation in the Comments pane”

I pointed this out several years ago.

And matters may (or may not) have changed in more recent versions if MSFT changed te internal code to use native, instead of WordBasic, code.

Working thru the WordBasic object should be reduced to a minimum, especially since we do not yet know what will happen in a ,NET-ized version of Word.
I doubt that MSFT Wil ldrop the WordBasic object, but I would at least expect the critter to be deprecated.

IMHO, I would prefer to use Captions rather than IDs.
In the worst case, I would use a Case Else that used the ID and other Cases would use th eCaption appropriate for the languageID.

Of course, there is no guarantee, as MSFT has also changed captions and/or re-arranged menus in the past.
So version checking is also required.

Reply | Quote

“Another weird thing I found today is that not all built-in commands do the same as the WordBasic commands with the same name (something I found to hold true until today): InsertAnnotation adds a comment in the Reviewing pane, WordBasic.InsertAnnotation in the Comments pane”

I pointed this out several years ago.

And matters may (or may not) have changed in more recent versions if MSFT changed te internal code to use native, instead of WordBasic, code.

Working thru the WordBasic object should be reduced to a minimum, especially since we do not yet know what will happen in a ,NET-ized version of Word.
I doubt that MSFT Wil ldrop the WordBasic object, but I would at least expect the critter to be deprecated.

IMHO, I would prefer to use Captions rather than IDs.
In the worst case, I would use a Case Else that used the ID and other Cases would use th eCaption appropriate for the languageID.

Of course, there is no guarantee, as MSFT has also changed captions and/or re-arranged menus in the past.
So version checking is also required.

Reply | Quote

I think “DrawGroup” is an example of what Howard warned about: a command which changed its Id.

And it wreaks havok with intercepting the command, because Word still uses the old Id in many places.

If you add “DrawGroup” to some toolbar or menu using its real, new Id, it will be intercepted:

Dim a As CommandBarControl
Set a = CommandBars("Menu Bar").Controls.Add(ID:=3454)
' while this would raise an error:
' Set a = CommandBars("Menu Bar").Controls.Add(ID:=164)

There are quite a few drawing commands with changed Ids in Word2002/2003 (DrawBringForward, DrawFlipVertical, …).

I would still use the Ids in my code. If MS messes with them, the code probably won’t work any more anyway.

Another weird thing I found today is that not all built-in commands do the same as the WordBasic commands with the same name (something I found to hold true until today): InsertAnnotation adds a comment in the Reviewing pane, WordBasic.InsertAnnotation in the Comments pane.

Klaus

Reply | Quote

Yes, I was trying to say the same ting, but my wording was sloppy.
I have many, many personal distractions now.

Reply | Quote

Yes, I was trying to say the same ting, but my wording was sloppy.
I have many, many personal distractions now.

Reply | Quote

I understand your argument on the first part. That is a risk. But I’m not sure I understand this one:

> However, executing the control item directly is unlikely to afect which code iis executed.

If I execute the ID for File>Save on my computer, the custom code for our document management system (Sub FileSave in a global template) intercepts the action and runs as expected.

Reply | Quote

Using IDs is not a reliable approach.
Ids can change from version to version of Word, I’ve seen it happen.
One could try using the control name instead of the ID.

However, executing the control item directly is unlikely to afect which code iis executed.

Reply | Quote

This approach works perfect for buttons. It even allows me to cancel the user actions. But for combo boxes, it only notifies me. What’s worse is that for some complex controls (such as undo, font color, fill color), it does not work any more. When the attatched combo box changes, I get the notification. But if the main button (e.g. undo button) is clicked, there is no way to intercept it.

Is there anyting complemetary to this approach?

Regards

Reply | Quote

I don’t think it’s a limitation of combobox controls or more complex controls generally.
Those controls looked exactly the same in Word6, and it wasn’t any problem to intercept them then.

The problem is that MS has messed them up. I have heard several promises in the last years that things will get better in the next version, but they generally get worse.

You could (re-)create your own, properly working controls, though that might be difficult to impossible in VBA. I heard it’s easier in .NET, but that’s just hearsay.

Klaus

Reply | Quote

I don’t think it’s a limitation of combobox controls or more complex controls generally.
Those controls looked exactly the same in Word6, and it wasn’t any problem to intercept them then.

The problem is that MS has messed them up. I have heard several promises in the last years that things will get better in the next version, but they generally get worse.

You could (re-)create your own, properly working controls, though that might be difficult to impossible in VBA. I heard it’s easier in .NET, but that’s just hearsay.

Klaus

Reply | Quote

Sounds as though it would be easier to download the source code for OpenOffice.org and customize that rather than fight through all these idiosyncracies in MS Office.

But seriously, as you’ve discovered some of the controls in the interface are not buttons and don’t have a straightforward way to interact with them. The help file lists many interesting control types, but it’s not clear which you can instantiate when, or whether that would even help. You’re probably learning more about these controls than most people would ever want to know…

If you have some event monitoring code that isn’t working the way you’d like, could you post a demo document? This will shortcut the process of people experimenting with it, and maybe get you more concrete comments.)

Reply | Quote

Hi, Jefferson. Do you something like this attatchment? In this document, there are some sample macros. SetHook( ) tries to set an event hook for the font color button. However, when I assign that control to a button variable, the VB interpreter says that “type mismatch”. In fact, it is not a “msoControlButton” but a “msoControlSplitDropdown”. Although a variable of msoCommandBarControl type can handl it, but such a variable does not any event.

Actually, I found 3 approaches to intercept the commands for Word. The first 1 is to set the event listeners for buttons. The second one is to change the onAction attribute. The last one is to create overriding macros with the same command name. None of them is a complete solution, but I am considering whether a combination would meet my requirement.

Reply | Quote

You’ll notice you can “tear off” the font color control into its own CommandBar. This makes it a tiny bit easier to reference the three controls (Automatic Color, Color, and More Colors…), but doesn’t solve the problem that there is no event model associated with those types of controls. As you point out, they are neither buttons nor combo boxes. They seem to be inside something called an msoControlGrid, but I don’t know any way to listen for that kind of control. Bummer! Hopefully one of your other methods will work. Or build your own color control. (Actually, I posted one on the Outlook board recently for a completely different purpose (involving the color of grid lines); they are a lot of work.)

Reply | Quote

You’ll notice you can “tear off” the font color control into its own CommandBar. This makes it a tiny bit easier to reference the three controls (Automatic Color, Color, and More Colors…), but doesn’t solve the problem that there is no event model associated with those types of controls. As you point out, they are neither buttons nor combo boxes. They seem to be inside something called an msoControlGrid, but I don’t know any way to listen for that kind of control. Bummer! Hopefully one of your other methods will work. Or build your own color control. (Actually, I posted one on the Outlook board recently for a completely different purpose (involving the color of grid lines); they are a lot of work.)

Reply | Quote

Hi, Jefferson. Do you something like this attatchment? In this document, there are some sample macros. SetHook( ) tries to set an event hook for the font color button. However, when I assign that control to a button variable, the VB interpreter says that “type mismatch”. In fact, it is not a “msoControlButton” but a “msoControlSplitDropdown”. Although a variable of msoCommandBarControl type can handl it, but such a variable does not any event.

Actually, I found 3 approaches to intercept the commands for Word. The first 1 is to set the event listeners for buttons. The second one is to change the onAction attribute. The last one is to create overriding macros with the same command name. None of them is a complete solution, but I am considering whether a combination would meet my requirement.

Reply | Quote

Sounds as though it would be easier to download the source code for OpenOffice.org and customize that rather than fight through all these idiosyncracies in MS Office.

But seriously, as you’ve discovered some of the controls in the interface are not buttons and don’t have a straightforward way to interact with them. The help file lists many interesting control types, but it’s not clear which you can instantiate when, or whether that would even help. You’re probably learning more about these controls than most people would ever want to know…

If you have some event monitoring code that isn’t working the way you’d like, could you post a demo document? This will shortcut the process of people experimenting with it, and maybe get you more concrete comments.)

Reply | Quote

This approach works perfect for buttons. It even allows me to cancel the user actions. But for combo boxes, it only notifies me. What’s worse is that for some complex controls (such as undo, font color, fill color), it does not work any more. When the attatched combo box changes, I get the notification. But if the main button (e.g. undo button) is clicked, there is no way to intercept it.

Is there anyting complemetary to this approach?

Regards

Reply | Quote

Maybe a better test is whether you can intercept this:

CommandBars.FindControl(Id:=164).Execute

(Of course, you should be able to intercept it by setting up a class to watch for CommandBar events… some past examples:

Word:	Re: Disabling Email in Word (Office 2000 Word)
PowerPoint:	Re: Autosave everytime i quit power point (2000)
Outlook:	Re: Outlook COM ADD IN (Office XP VBA6)

I think the question is: is there a simpler way in this case?)

Reply | Quote

Option Explicit

Private Sub TestIntercept()
DrawGroup
End Sub

Public Sub DrawGroup()
Debug.Print “DrawGroup intercepted”
End Sub

Reply | Quote

Hi Howard,

I was unable to intercept DrawGroup in Word 2003 (and it doesn’t show in the list of commands generated by the ListCommands command). Command command command.

What were you doing when you invoked the command and intercepted it?

Reply | Quote

I tried in both 2K and XP but failed in both. I do not have a Word 2003 at hand so cannot test. Is it a bug only solved in 2003? But it seems unlikely.

I put the Sub in the “All active templates and documents”. The code is rather simple and I cannot see any error in it.

Sub DrawGroup()

MsgBox (“Group”)
WordBasic.DrawGroup

End Sub

Reply | Quote

I Just rebooted to a system with Word 2002.
I was able replace DrawGroup.

In all cases, I am (ab)using English (US) version of Word.

Perhaps, those having problems have not installed particular Word options?

Reply | Quote

Hi Howard,

Thank you for providing your example.

I’m a bit unclear as to what your “TestIntercept” procedure demonstrates, other than the ability to run another procedure, named “DrawGroup”. I can certainly replicate that, but the “DrawGroup” procedure is not run when I choose Draw->Group from the interface.

I will investigate my installation options settings (I’ve no personal need to intercept DrawGroup, just curious as to why it would work on another system with Word 2003, and not mine).

Regards,

Reply | Quote

Hi, Andrew. I cannot make it work with Howard’s code either. If you find the reason, can you put it here please?

Thanks

Reply | Quote

Hi, Andrew. I cannot make it work with Howard’s code either. If you find the reason, can you put it here please?

Thanks

Reply | Quote

Hi Howard,

Thank you for providing your example.

I’m a bit unclear as to what your “TestIntercept” procedure demonstrates, other than the ability to run another procedure, named “DrawGroup”. I can certainly replicate that, but the “DrawGroup” procedure is not run when I choose Draw->Group from the interface.

I will investigate my installation options settings (I’ve no personal need to intercept DrawGroup, just curious as to why it would work on another system with Word 2003, and not mine).

Regards,

Reply | Quote

I Just rebooted to a system with Word 2002.
I was able replace DrawGroup.

In all cases, I am (ab)using English (US) version of Word.

Perhaps, those having problems have not installed particular Word options?

Reply | Quote

I tried in both 2K and XP but failed in both. I do not have a Word 2003 at hand so cannot test. Is it a bug only solved in 2003? But it seems unlikely.

I put the Sub in the “All active templates and documents”. The code is rather simple and I cannot see any error in it.

Sub DrawGroup()

MsgBox (“Group”)
WordBasic.DrawGroup

End Sub

Reply | Quote

I can interecept DrawGRoup in Word 2003.
The Sub must be Public and must be avaiable in the project or, maybe, in a global template.

Reply | Quote

Hi, Hans. Thanks for you quick reply.

I have read that command list, but still have something that I cannot understand. For example, the command DrawGroup is in the list but cannot be intercepted by creating a macro with the same name. Are all the commands in the list interceptable or do I need other techniques to do so?

Regards

Reply | Quote

Wow – I downloaded that list of Word commands. Thank you so much Hans – its brilliant!

Reply | Quote

Wow – I downloaded that list of Word commands. Thank you so much Hans – its brilliant!

Reply | Quote

DrawTextBox (I don’t know DrawInsertTextBox) is an internal Word command (the equivalent of Insert | text Box); it can be intercepted. There is no separate Word command for ovals, so there is nothing to intercept. You can download a list of Word for Windows commands, and their descriptions, default shortcuts and menu assignments from the Word MVP site.

Reply | Quote

You could experiment with intercepting CommandBar events. See post 388718 (further up in this thread) for some code examples. I think in the past someone described a good way to iterate through the command bars to extract IDs, but that probably would take some energy to find. You can get a sense by using the Locals window and simple code like this (look for .Caption and .Id):

Sub SniffDrawingCBar()
Dim cBar As CommandBar
Set cBar = CommandBars(“Drawing”)
Stop ‘ Drill down through Controls collections in the Locals window
Set cBar = Nothing
End Sub

Hope this helps.

Reply | Quote

I think it works better to monitor the button events than my initial idea to override the buttons. It also works for other Office application. I will try this one.

Thanks, Jefferson.

Reply | Quote

I think it works better to monitor the button events than my initial idea to override the buttons. It also works for other Office application. I will try this one.

Thanks, Jefferson.

Reply | Quote

You could experiment with intercepting CommandBar events. See post 388718 (further up in this thread) for some code examples. I think in the past someone described a good way to iterate through the command bars to extract IDs, but that probably would take some energy to find. You can get a sense by using the Locals window and simple code like this (look for .Caption and .Id):

Sub SniffDrawingCBar()
Dim cBar As CommandBar
Set cBar = CommandBars(“Drawing”)
Stop ‘ Drill down through Controls collections in the Locals window
Set cBar = Nothing
End Sub

Hope this helps.

Reply | Quote