Hooking BuiltIn Controls

Whereas most of RibbonX concentrates on customizing the visual appearance of the Ribbon, the commands and command elements provide a mechanism for overriding any built-in menu, to modify its enabled state or to intercept any button clicks. To achieve that, you can include the following XML to, say, override the Print button so you can set up some formatting:

<customUI xmlns="http://schemas.microsoft.com/office/2006/01/customui"> <commands>

<command idMso="FilePrint" onAction="rxPrint_onAction" /> </commands> </customUI>

The command element can only have an enabled attribute or getEnabled and/or onAction callbacks. You could, for example, disable a control by including enabled="false", or use a getEnabled callback to determine whether or not to enable the control depending on the state of the application. The onAction callback is used to intercept the default behavior, allowing you to do some preprocessing and optionally cancel the action:

'Callback for Print onAction,

with ability to cancel

Sub rxPrint_onAction(control

as IRibbonControl, ByRef cancelDefault)

If CDbl(Time) > 0.5 Then

Msgbox "Printing can

only be done in the morning!"

cancelDefault = True

End If

End Sub

Unfortunately, overriding Ribbon controls in this way only affects the user actually clicking the control or using the Alt+Key shortcuts to trigger the control; it does not intercept the many operations that can be achieved using the function keys and Ctrl+Key combinations (such as Ctrl+P in this case).

If two add-ins attempt to override the same control, the last-loaded add-in wins. For these two reasons, the ability to override a built-in control should be used with extreme caution.

0 0

Post a comment