While working on customizations, we often look for better ways to accomplish our goals. We recently discovered a quick way to make ArcMap buttons more versatile through development, and the result can be very useful.

ArcMap buttons are versatile. When creating a custom button, developers have always had the ability to specify logic to determine whether or not the button should be enabled using the Enabled() method. This is evaluated frequently through code, allowing the developer to have control over whether or not the button can be pressed. The button does visually indicate to users that it is disabled under the proper conditions.

With that said, we’ve frequently run into a user experience issue with Enabled() that causes it to be used significantly less than theoretically intended. This is because the user doesn’t know why the button is disabled. Should the user be in an edit session? Does the user have invalid permissions? Is there a layer missing?

The problem is that these users have no idea – the button just doesn’t work and there’s no indication of how to make that change.

Traditionally, this has been taken care of by relegating this Enabled() method to a much lower priority, and only giving it much more rudimentary logic where it should be fairly obvious why users can’t click on the button.

Using this method, when a user might need to know exactly why the button is disabled, he or she is still able to click on the button, but a message box or a similar warning will display, telling the user why the tool can’t yet be used. This isn’t a bad solution, but we’ve been looking into another possibility:

The approach here is to change the tooltip message every time that the Enabled() method is called. Every time the user hovers his or her mouse cursor over a disabled button, the description will be displayed, followed by a short message indicating why the button is disabled. This is actually a very easy task to implement in most code.

As a developer, simply add a class variable to your button to indicate any possible error messages, assign to this variable every time the Enabled() method runs (regardless of whether or not the tool is disabled), and add to the ToolTip property’s string  to retrieve this disabled text after any standard description for the button (or, if desired, replace the description with this text).

You also have the option of overwriting the text in the status bar when a button is disabled using the Message property.

That’s all there is to this approach. It’s a promising alternative to adding custom logic. Consider building it into your buttons and base classes and trying it yourself!