(Translation) learnvsxnow! #13-Vs menus and commands in IDE

Almost all vspackage users interact with each other. You can click the menu or toolbar in Visual Studio to activate the vspackage function or display related interfaces.

In this articleArticleTo see how Visual Studio menus and toolbar are defined, created, displayed, and used. However, I just want to talk about some basic knowledge in this article. In the next article, let's look at some examples.Code.

Concepts

The vspackage function we created can be called by other packages or used by end users. It can be called "command" by end users )", such as printing and adding files.

However, if you want to use our commands, you must provide them with a certain method. The most common method is to create a menu item. You can click the menu to use these commands. In addition, we can also allow users to input text in a similar console to call our commands, such as the vs command window (View | other Windows | command window ).

Visual Studio has the same menu and toolbar functions: When you click them, vs calls the commands bound to them. For a command, it does not know whether it is called by the menu or by the toolbar.

1. Menus are usually displayed at the top of IDE, and menu items are displayed in groups. Some ide elements (such as tool window, document window, and window frame) also have their context menus, it is displayed when you right-click them.
2. A toolbar is usually a collection of controls. These controls have the same functions as menu items: they are used to execute commands. These controls can be buttons, drop-down boxes, list boxes, text boxes, or separated buttons.

Therefore, in this article, whether it is a menu item or a control on the toolbar, I will use the name "menu item" to represent them.

Static and dynamic menu items

Menu items can be static or dynamic. Static means that these menu items will only be instantiated and initialized once (usually during package initialization), and their statuses will be retained from the beginning to the end; dynamic means that after initialization, these menu items can change their status or appearance, or dynamically create these menu items based on context information. A good example of static menu items is to display the menu items in a tool window, and a dynamic menu item is the menu item "Recent File.

Concept of distinguishing menus and commands

In traditional Windows Forms development, developers often attach the same event processing method to multiple menu items or toolbar items, and process the statuses of these menu items or toolbar items respectively. For example, if a menu item and a toolbar item have the same function, they will attach the same event handling method to the menu item and toolbar item, and process their enabled/disabled statuses respectively.

However, in Visual Studio, the concepts of menu items and commands are more clearly differentiated.

The command determines its status (display name, visibility, availability, and so on), and executes the command processing method. The menu item is responsible for displaying the appearance of a command, it also provides a method for users to trigger commands.

This means that a command can be bound to zero, one, or more menu items. The command itself knows its status and reports the status to related menu items: developers only need to set the command status, you don't have to worry about how many menu items are associated with it. Menu items automatically adjust their appearance Based on the command status.

Concepts of distinguishing commands from command targets

Now we have figured out the differences between menu items and commands. Let's take a look at another thing to be clear: when calling a command, the command itself may not know what code logic to execute.

A command is only a logical entity. The Command target knows how to execute the command. In vs IDE, there is a command routing model that can forward a request to the Command target. The Command target can execute the logic related to the command, or do nothing, indicating that it does not support the command (for example, the target does not know how to handle the command ). Command targets can even be transferred to other command targets for processing.

Let's look at an example. On the "edit" menu and Visual Studio Standard toolbar, there are cut, copy, and paste menu items, these menu items can even be added to some right-click menus. These menu items are bound to the cut, copy, and Paste commands. In fact, no single object in Visual Studio knows how to execute these commands. Ide forwards the request to the corresponding Command target based on the current context information. For example, if the current active window is a text editor, IDE forwards the command to the text editor. When the attribute window is used, the command is transferred to the attribute window; when the aspx designer is used, the command is transferred to the aspx designer. Therefore, the text editor, attribute window, And aspx designer are all command targets. These command targets decide whether to support the commands to be transferred.

Summarize these concepts

Now let's summarize the concepts related to commands:

Concept	Responsibilities
Menu item (menu item and toolbar item)	Provides an interface for commands and displays the interface based on the command status.
Command)	Is a logical entity, which does not necessarily contain the command execution logic.
Command target)	The Command target knows how to execute a command. It can forward, execute, or even reject a command. It can also control the command status.

 

Process menu items and commands in Visual Studio

In this section, let's take a look at how vs processes menus and commands.

Command visibility

Some menus and toolbar in vs are displayed or hidden Based on the context. For example, the "project" and "debugging" menus are invisible when the project is not opened; you cannot see the team menu before it is connected to the team server.

Commands can be defined in the following places (or logically in these places ):

1. Vs IDE.All commands defined in vs IDE are visible.
2. Package.Package determines whether to display the commands defined by package. In addition, do not forget that most of VS is composed of various packages.
3. Active project ).At the same time, only one active project exists in vs. Only commands belonging to the active project are visible.
4. Active editor ).If multiple files are opened at the same time, there will be only one active editor at the same time. Only the commands in the editor that belong to this activity are visible, and the commands in other editors are invisible. In addition, some designers support different file types (such as image editor). Some commands may be available for one of the file types, but not for other file types. For example, we can set the transparency for an ico file, but not for a BMP file. Therefore, displaying different commands Based on the file type is also the responsibility of the editor.
5. Tool window ).The tool window also has its own commands.

Context of visibility

You may feel that we missed an important thing and didn't talk about it. For example, the project and debugging menu are invisible before the project is opened. However, how does Visual Studio hide commands without opening the project and display commands after opening the project?

Visual Studio allows us to further control the command visibility. IDE defines some contexts, and the command visibility can be bound to these contexts. These contexts are as follows:

Context name	Description
Nosolution	No solution is enabled in vs IDE (the solution browser is blank at this time)
Solutionexists	The solution is enabled in vs IDE. It can be an empty solution, a solution automatically created by opening a file, or a solution containing one or more projects.
Emptysolution	Vs ide opens an empty solution (this solution does not contain any items)
Solutionhassingleproject	Vs ide opens a solution that contains only one project.
Solutionhasmultipleprojects	Vs ide opens a solution that contains multiple projects.
Solutionbuilding	The current solution or any of the projects is being generated. The context is invalid after generation.
Debugging	Vs IDE is in debugging mode: the debugger is attached to a process.
DesignMode	Vs IDE is in design mode (that is, not debug mode)
Fullscreenmode	Vs ide runs in full screen mode (you can click the "View | full screen" menu to enter full screen mode)
Dragging	A drag operation is ongoing in vs IDE.

If a command is bound to multiple contexts, this command is visible when vs IDE is in one of the contexts.

Command routing and context nesting

Objects in vs IDE, package, and package (such as editors and Tool Windows) define many commands. Depending on the current context, a command can be executed by different command targets.

Visual Studio has a good routing structure that specifies the rules for command execution within a certain context. This route starts from the innermost context and forwards requests to the innermost context until it is transferred to the global context. Each context has a so-called Command target for executing commands.

So what is the "Innermost" context and the "Global" context?

Context can be nested. For example, if we create a package with a tool window and register it in vs IDE, we have the following structure context:

1. The outermost (global) context is vs ide itself.
2. After our package is loaded to the IDE, the package's own context is a context nested in vs IDE.
3. After a tool window is created, the context of the tool window becomes the context nested in the package.

RoutingAlgorithmFrom the leaf node of the context nested tree, it is always bubbling to the root node of the tree, that is, the global context.

Routing Algorithm

The node to which the command bubbles is called "active command context ". If the object representing the context of the active command is not a command target, the command will continue to bubble to the upper-level node. If the context of the active command is a command target, you can process the command, or tell the IDE "I don't know how to handle this command", the command will continue to bubble up.

The routing algorithm defines the following levels (from leaf nodes to root nodes ):

1. ExternalProgram(Present add-in). The command is first passed to the registered and loaded external program (add-ins ).
2. Context menu (shortcut menu ). If the command is in the Context menu, the target object of the command that belongs to the context menu can process the command.
3. Window with focus. The current window with focus is the next object that can process commands. Windows can be tool windows or document windows. Each type of window processing commands is different.
1. Document window ). We haven't talked about the document window yet. In future articles, we will use a topic to explain it. The document window consists of two parts: the document view used to display the document and the document data used to process the document information. The command is first passed to document view. If document view does not support this command, it will be passed to document data.
2. Tool window ). Some tool windows will pass commands within themselves, such as the solution browser, which will pass commands from the leaf node to the solution node in turn within itself.
4. Current Project. If the current project cannot process commands, the commands will be transferred to the upper-level node until the solution node. (Vs SDK allows the creation of subproject types (namely, flavor projects). Therefore, the parent node of a project is not necessarily a solution node ).
5. Package. Each package should process its own defined commands. Although theoretically this is not necessary, since the package cannot process these commands, what should we define them?
6. Global level. If the command is not processed in the previous several levels, it will be transferred to the global level.

Package loading on demand

In article 5, I mentioned that a package is loaded on demand, that is, when an object (such as a toolbar or editor) in a package is created, or the package service must be called elsewhere before the package is loaded into the memory. However, a package contains a menu. If a package is loaded to display the menu, the on-demand model does not look like that. How can I display the corresponding menu without loading the package?

The key lies in the registration of package(see section 8 about regpkg.exe ). By registering a package, the corresponding menu is saved to the Registry. Visual Studio displays menus by reading information in the registry. After you click a menu, Vs will find the corresponding package. If the package has not been loaded, perform the following steps:

1. Load the relevant Assembly to the memory.
2. Create an instance of the package class (by calling the default constructor of the package class ). At this time, our package does not know any context about, therefore, we cannot put context-related initialization code in the package Constructor (for example, trying to access a vs service ).
3. Load (SITE) package. In this case, our package is loaded into.
4. Call the initialize method of the package. We can override this method and put some initialization code. Here we can put some Code related to the vs context. In addition, if our package defines a menu, we should also bind the menu and the corresponding command here.

After a user clicks a menu, vs finds the relevant command and runs it. If we forget to bind the menu to the command, clicking the menu will not respond-of course, although there is no response, our package will be loaded as a result.

In addition, I mentioned that the command target will be responsible for updating the command status. If the routing algorithm routes data to a package that is not loaded to the memory, vs does not load the package, instead of using the initial state of the command.

 

Summary

In this article, I will give you a brief overview of menus, menu items, toolbar, commands, and command targets.

Visual Studio separates the UI from their corresponding functions. In different contexts, the same command (such as cut, copy, and paste) may execute different actions.

Visual Studio defines the concept of command targets. A command target knows how to update the command status and how to execute the command. Vs ide defines a routing algorithm that forwards commands to different levels of command objects.

In the next article, let's take a look at the vsx type used to implement the concepts we mentioned today.

 

Link: http://dotneteers.net/blogs/divedeeper/archive/2008/02/22/LearnVSXNowPart13.aspx