We Keep Coding

Debugging hotkey collisions - a XAML with all included views?

I'm maintaining a large c# XAML-based UI project which uses several embedded common or at least reused XAML controls. As in, like,
<shared:DirectionsView DataContext="{Binding DirectionsViewModel}"/>
The problem comes when I try to define hotkeys for new buttons in one UI that happen to already be in use in some included control. I can see the embedded control directly in the XAML editor, but if I want to add ALT+V as a hotkey somewhere, searching the XAML I'm editing for "_v" isn't going to find something in the DirectionsView that's hotkeyed that way.
Is there some file, maybe generated during the build process, that is the "final XAML" or otherwise represents the form with all inclusions in it? That way I'd at least have something to probe.

Is there some file, maybe generated during the build process, that is the "final XAML" or otherwise represents the form with all inclusions in it?
No, there isn't. The visual tree is composed at runtime when the XAML processor parses the BAML (the compiled XAML) and actually creates instances of the runtime classes such as your DirectionsView class.
So you will have to search through the different source files and compose your own "final" element tree "manually" I am afraid.

How to create a VS 2008 Windows Forms project programmatically, that can be maintained just like any other project created manually

I have a bunch of control properties (type of control, location, size, etc.) derived as a text file from an old system on a different platform. I thought it would be fairly easy to load these "control descriptions" into a Windows Forms project in VS 2008 and then be able to maintain the new project in VS just as if it had been created manually.
I'm familiar with using VS and C# but it I'm not sure where to start with this.
I searched the web and found a number of articles about creating controls on forms at run time and that is not so hard, given the information I have, but I want the created form to be a permanent part of a Win Forms project, so I need to get what was created at run time into VS, and accessible in the project just as if it had been manually dropped on the designer surface. Is there a way I could create these forms with a program and then "save" them in a form acceptable to VS?
I manually created a windows Form project to try and use as a "template" and identify how VS does it. I have tried to understand the contents and the relationships between the various resource files, but it is a bit too much. There are also warnings that various files are created by VS and should not be amended manually.
I have almost 1000 forms from the old system so the thought of manually having to add each one to VS is pretty non-viable. I could translate the text descriptions into XML if there is a way to feed an XML description of a Form into a VS Forms project...?
Any advice\direction towards this would be greatly appreciated.

VS uses code generation to create controls in Windows Forms. If you look at a form e.g. Form1 that's in your project, it consists of three files, Form1.cs, Form1.designer.cs and Form1.resx. The Form1.designer.cs file contains the construction of the controls in the InitializeComponent method. VS executes this and parses it at design time to give you the design view of the form where you can make modifications. You could write a program to parse your text files and generate C# code for InitializeComponent to get the right effect. There are various options but you probably would want to use the CSharpCodeProvider class.
Another option is to use WPF. Forms are designed in WPF using XAML, which is an XML based format. (By that I mean, an XAML document is also a valid XML document, but the reverse is not true.) If you create a WPF project and add some controls to it then you could take a look at the XAML file to get an idea of the structure.

Add custom editor windows to Visual Studio window panes

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
Programatically create a dockable window pane
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.

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.

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.

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...

Visual Studio 2010 C# Form Project - Drag and Drop - best method?

My aim is to create an application whereby a user can drag a label from a tabbed container into some form of holding area - which had a ruler and a basic grid. I have consulted Google on the subject but the tutorials seem to involve dragging and dropping form components in design view.
The final aim is to then take my holding area and translate that into a .xml file - whereby each dropped element has an entry as follows:
[Dragged Component Name][X Co-ordinate][Y Co-Ordinate][Other Param's].
Any help with both aspects would be very much appreciated - this is just for a demonstration to a colleague.

I think you need something like this:
http://msdn.microsoft.com/en-us/magazine/cc163871.aspx
This link contains information on creating form designing forms looking exactly like Visual Studio Forms Designer. This way you may need to handle less situations than writing a forms designer with conventional methods.

Using C# WinForms Designer on Panel instead of Form?

Warning: I'm new to GUI building in C# (come from a long history in Java with Swing and SWT.)
Using VS2008, When I create a new class, and extend System.Windows.Forms.Form, the WinForms Designer works really nicely. However; when I create a new class and extend System.Windows.Forms.Panel, the designer does not work nearly as elegantly - it simply shows some kind of abstract, list-type view of the components contained in the Panel (as opposed to showing the actual layout of the Controls in the Panel.)
Is there a way to get the Designer to work more nicely with a Panel?
Or is there some workaround so that I can build a Form with the designer, and then use it as if it were only a Panel?
What I'm really looking for is some UI 'element' I can build with the designer, and then dynamically (read: programmatically) add/remove that 'element' to a larger UI.

I think what you're looking for is a UserControl. You can inherit directly from that, and you should be able to use the designer to drag and drop stuff on it.
To make it even easier, you can just right click on your project and click Add -> User Control. That will create the .cs file for you as well as a partial .cs file for the designer generated code.