Partager via

Commands and UI

  • Article

(Copied from weblogs.asp.net/craigskibo)

Today was a big source code check-in day. I sent well over 50 files to be checked
into our source code control system, and I will be here late sending off a lot more.
What kind of things did I change? Well, one of the most asked for features is the
ability to add different UI types to a CommandBar, and with different settings.

"urn:schemas-microsoft-com:office:office" />

 

For example, today when you call Commands.AddNamedCommand we will create a command.
You can then add UI to a command bar for that command with the Command.AddControl
method. But that UI element is always a button, not combo boxes, not menu controllers
(the split drop-down button like that for the undo / redo command), etc. The change
for Whidbey allows you to specify which control type should be used. This is the enum
that contains the different control types available (this list is subject to change,
either with the addition or subtraction of additional elements):

 

    enum vsCommandControlType

    {

        vsCommandControlTypeSeparator
= 1,

        vsCommandControlTypeButton
= 2,

        vsCommandControlTypeMenuButton
= 4,

        vsCommandControlTypeSwatch
= 8,

        vsCommandControlTypeSplitDropDown
= 16,

        vsCommandControlTypeDropDownCombo
= 32,

        vsCommandControlTypeMRUCombo
= 64,

        vsCommandControlTypeDynamicCombo
= 128

    } vsCommandControlType;

 

The second problem that people have with the AddNamedCommand/AddControl combination
is in how all commands you create have both text and a picture, you cannot change
the UI to have just text, just the bitmap, etc. This is the enum that we have defining
the different types available (again, subject to change):

 

    enum vsCommandStyle

    {

        vsCommandStylePict
= 1,

        vsCommandStyleText
= 2,

        vsCommandStylePictAndText
= 3,

        vsCommandStyleContextUseButton
= 4,

        vsCommandStyleTextMenuUseButton
= 8,

        vsCommandStyleTextMenuControlUseMenu
= 16,

        vsCommandStyleTextCascadeUseButton
= 32,

        vsCommandStyleComboNoAutoComplete
= 64,

        vsCommandStyleComboCaseSensitive
= 128

    } vsCommandStyle;

 

Of course, we have fixed a number of the usability problems developers would have
when developing Add-ins. In versions of VS prior to Whidbey, if you would run the
Add-in wizard, press F5, then kill the debugged process, you command would be lost
and you would need to run devenv /setup to reset the state (which would also reset
any of your customizations). We changed when we save data saying that the UISetup
stage of your Add-in ran from startup to shutdown, fixing this common problem. We
also decided today on a few other enhancements to make developing Add-ins easier,
stay tuned for more details…

Comments

  • Anonymous
    February 12, 2004
    Craig -
    This is cool. Any more insight as to what automation developer can expect to see in Whidbey? I'd love a hsort list if you have the time...
  • Anonymous
    February 14, 2004
    One area that we have tried to improve is .NET interop, removing some of the problems in using the object model from .NET such as eliminating COM registration, packing images into IPicture interfaces, removing using ActiveX controls on tool windows, etc.