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:

https://i.sstatic.net/e5HeL.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.

Animalcule

The samples you want come with the Visual Studios SDK. Since they don't show any updadted versions, I would expect that the latest version would have the same samples – Showily

There's no Visual Studio 2012 SDK samples, but there are 2010 samples. I've looked through them all and none of them are the ones mentioned in the VS 2005 links I provided. I believe the 2010 samples are meant to highlight the WPF interfaces they added for that version of Visual Studio. – Animalcule

Hi, Josh. I've come upon your question from looking for exactly the same kind of extension (after reading Clean Code). Did you have any luck with finding \ building an alternative to Debugger Canvas? P.S. Just realized, you are the guy behind Shotgun Debugging Roslyn tutorials - thanks for them :-) – Knut

I used the information I learned here to build codeconnect.io with a friend of mine. However, it's for exploring code rather than debugging it. Thanks, glad you find them helpful :) – Animalcule

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.

Plerre

This looks very promising and at the very least should introduce me to this InvisibleEditor manager. I'll be looking more into this code this weekend. – Animalcule

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.

Scutch

Thanks for the response, I've actually already posted on the forums:social.msdn.microsoft.com/Forums/vstudio/en-US/… I've also reached out to the code canvas guys but didn't hear back. I'm not in Seattle, but a friend who is working on this will be soon, I'll let him know. Thanks for the tips! – Animalcule

You're welcome. There's an email address I want to tell you that you should email, but I have no way of finding your email address (I'm not sure if I can share the email publicly). Put your contact info on your blog! :) Email me at ameen at triangle dot io so that I can share it with you. – Scutch

Answer 3

You need to register a tool window with your package extension; this can be done via the ProvideToolWindow attribute. The following article contains all the required information on how an editor can be hosted in a tool window: http://bit.ly/9VWxPR

Take a look at the WpfTextViewHost class; the article explains that this type is actually an UIElement, so I imagine that it´s possible to host multiple instances of it...

Gonad

You can place it in a tool pane, but you aren't required to. – Plerre