Regenerating Commands and Their User Interface


As you are developing your add-in, you may need to add, remove, or modify the attributes of the commands that you are creating. If you were to run the add-in wizard and select the option to create a Tools menu command, the appropriate code to generate a menu item is generated. After running the wizard-generated add-in, if you select the Tools menu, you will see the newly created menu item. But suppose you needed to modify this code to create a combo box instead. If you were to make the appropriate modifications to the code, compile, and then from the Windows Start menu, start a new instance of Visual Studio, the item on the Tools menu will still be a menu item. Why is this?

When the code for a wizard is generated, the appropriate tag is placed into the .addin XML file indicating that the add-in wants to generate a command. When Visual Studio runs, it notices this tag, the add-in is loaded, and the UI setup block of code (the portion of code that checks for the ext_cm_UISetup flag in the connectMode parameter of OnConnection) is run. But this portion of code is run only once; Visual Studio remembers if the add-in's UI setup block has been run, and it will not go through these steps again. Any commands and UI for those commands are persisted across instances of Visual Studio. This is a huge performance benefit, in that your add-in is not loaded and executed every time Visual Studio is run. If, after making the code changes to change the UI type, you were to run the new add-in again from within Visual Studio (by pressing F5 or Ctrl+F5, not from the start menu in Windows), the command will be changed. This happens because the wizard-generated code modifies how the wizard is run when launched from within Visual Studio. If you were to open the properties window for your add-in project and inspect the Debug tab of the properties window, you would notice that a command-line argument named /resetaddin is used. This switch directs Visual Studio to find all the commands and command UI owned by the specified add-in and remove them before starting. Visual Studio will then reload the add-in and execute the UI setup block of the add-in again, causing your commands to be regenerated.

The /resetaddin command-line argument requires a value when it is used. The first possible value is the fully qualified name (in the form of the Namespace.ClassName) of the add-in to reset. The second possible value is the asterisk character (*). When this value is used, all commands and their UI for all add-ins are removed. This gives you a way of cleaning up all add-ins at once. You can also use the /resetaddin switch if you are trying to delete an add-in from the system (such as from an uninstall program). First, you will need to delete the .addin file and any .dll files placed on disk for your add-in. Your uninstall program can then issue the command line devenv /resetaddin Namespace.ClassName /command File.Exit, where Namespace.ClassName is the fully qualified name of the class implementing the add-in. This will force all the commands to be deleted for the add-in, and the /command File.Exit command line switch will force Visual Studio to close when the commands have been deleted. Because the .addin file is no longer present, the commands for that add-in will not be re-created.




Working with Microsoft Visual Studio 2005
Working with Microsoft Visual Studio 2005
ISBN: 0735623155
EAN: 2147483647
Year: 2006
Pages: 100

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net