Add custom editor windows to Visual Studio window panes

Question

My Problem

I'm trying to build an extension to Visual Studio that allows code to be edited on a per-function basis, rather than a per-file basis. I'm basically attempting to display code in a similar fashion to Microsoft Debugger Canvas.

I'm wondering how to host multiple Visual Studio editors within a single window (I believe the windows are implementing IVsWindowFrame). The functionality I'm after can be seen below:

Each editor window retains typical functionality and interacts with third-party extensions as expected. (For example, VsVim functions correctly within these windows).

What I've Tried

I've spent almost two weeks researching and trying this stuff and I'm having a lot of trouble figuring out which services, interfaces and classes I'm going to be using.

Reading through MSDN

First off, most of the documentation discusses how to edit a single editor window and add adornments, tags, margins etc. It doesn't discuss the possibility of spawning multiple editors within a window pane.

I've looked through the documentation on a vast number of interfaces of interest to me including IVsTextBuffer, IVsTextView and IVsInvisibleEditor. Unfortunately I can't get some of these interfaces to play nicely together.

On top this, the usually excellent MSDN is extremely lacking in this area. Many of the interfaces contain only a list of members without even a basic remark on intended use and functional. (IComponentModel, for example).

Many of the interfaces make reference to a set of Editor Samples but the code cannot be read or downloaded on MSDN. Apparently it shipped with Visual Studio 2005, but I don't have this version of Visual Studio, nor can I find it.

Interacting with IVsUIShell

I can get access to all WindowFrames open using IVsUIShell.GetDocumentWindowEnum(); I see there is an IVsUiShell.CreateDocumentWindow() method, but I'm completely unfamiliar with the parameters it accepts, or if this is the correct path to go down.

What I need to do

1. Programatically create a dockable window pane
2. Programatically add editors to this window pane. (And ensure they're correctly registered within Visual Studio, the running document table, etc.)

Edit:

I'm sorry, I should have expanded on my steps. When I said I needed to register with the running document table and Visual Studio, it's because I want to actually edit the original document in my custom editor. Below is a short example of the functionality available in Debugger Canvas that I'm trying to recreate:

http://i.imgur.com/aYm8A5E.gif (I can't embed a .gif)

Alternatively:

If anyone knows where I can find the editor samples included with Visual Studio 2005 such as the Basic Editor Sample I'm sure I could figure this stuff out. The MSDN documentation has no code samples regarding these interfaces, which has made my job extremely difficult.

Answer 1

The Git Source Control Provider is an open source extension includes a tool pane that embeds a standard editor as a control within a custom WPF tool window. I would use this code as a reference for any Visual Studio 2010+ extension where I wanted to host an editor window in some custom location.

• PendingChangesView.xaml includes a ContentControl named DiffEditor, the content of which will be the editor.
• PendingChangesView.xaml.cs includes a method ShowFile, which calls a method to create the editor control and assigns the result as the content of DiffEditor.
• ToolWindowWithEditor.cs includes a method SetDisplayedFile which returns a Tuple<Control, IVsTextView> interface, which provides access to a Control that can be added to a ContentControl as well as the IVsTextView for the text view. The heavy lifting is in this method.

Note that the SetDisplayedFile method includes several lines with the following form:

textViewHost.TextView.Options.SetOptionValue({name}, {value}); 

These lines perform key functionality for the Git Source Control Provider such as removing margins and making the window read only. There are many options available, so you'll want to review the documentation for DefaultTextViewOptions and DefaultTextViewHostOptions to apply the ones appropriate for your particular extension.

Answer 2

I haven't actually looked at the files that @280Z28 (why this username?) posted. I used to work on the Visual Studio editor and what you are trying to do has multiple facets to it that you should tackle independently:

• Hosting multiple command targets inside a single IVsWindowFrame (this means that you'll have different elements inside the same pane from the point of view of Visual Studio's shell, and each of them need to have their own command handling. Consider the case where you put your caret in one of the mini-editors and want to undo using Ctrl+Z, moments later, you then place your caret into another mini-editor and do the same. Even though the WPF and Win32 focus have remained inside the same window frame (from the point of view of the Visual Studio Shell), the commands need to be routed to different components.
• Using editor's that are displaying parts of another document. The mechanisms here that will be your friend are in the projection namespace. Projection essentially allows you to project a piece of buffer (or buffers) into a view. Ellision buffers are special case projection buffers that project from one source buffer into a target view while hiding areas of the buffer (this is most likely what you want). An example of a projection buffer is what happens inside a cshtml file. In that case, there is one buffer containing all the C# code, one buffer containing all the javascript, and one buffer containing the html and each compiler works off of that buffer, but the end user sees a projection of all these buffers into the editor's view with only relevant parts displayed (for example C# import statements are elided even though they exist in the real C# buffer.)
• Managing the running document so that when an edit is made in a mini-editor, the real document is dirtied. You need to handle cases where the parent file is already open in the RDT in which case you want to dirty the same document when changes are made, and also cases where the document is not open, in which case you need to create a new entry in the RDT.

Also, please post to the Visual Studio forums, there are people who regularly check the forums and route the questions to corresponding devs.

Generally speaking, when it comes to the editor, avoid any traditional interfaces (anything that does not use MEF), so samples from Visual Studio 2005 should not be used as a reference point.

If you care enough and are in Seattle, you can try to go to campus as an MVP. There are days where you come to campus, and members of varying team will grab a laptop and come to your conference room and you can debug code together or hack away (while having access to debugging symbols and what not).

Last but not least, contact the code canvas guys, I'm sure they've solved many of the problems you are facing.