Custom Editor

Custom Editor

• C#wanabe

  On a side note, can someone tell me whether there is an "easy" way of getting a watch window pointer from either inside an add-in or a package, without having to implement a debugging engine Basically i want a simple interface via which i can get the list of variables in watch window (in simple text format, nothing fancy, much like list controls) and set the value or a variable in watch window (similar to list view control)
  
  
  

• JasonZ57666

  The implementation of an editor/designer generally involves three objects: 1. EditorFactory, 2. Editor View (aka DocView), and 3. Editor Document (aka DocData). The DocView object is the UI of the editor. This will be a window that fills the client area of the Document Window Frame. The DocData object handles the loading and saving of the document and generally owns the in-memory copy of the document. If your Editor supports multiple views to be open at the same time, then there will be multiple instances of Editor View objects but only one instance of the DocData object. Your EditorFactory object is the one that should know how to create instances of your DocData and DocView objects. If the document is already open in memory, then your EditorFactory objects needs to instantiate a new instance of a DocView object and hook it up to the already open DocDataExisting object. If you do not support this Data/View separation then you can arrange to implement a single object that handles the DocView interfaces as well as the DocData interfaces. The basic editor sample is such an editor that implements a single object. As such the sample is somewhat simplistic. The FigPkgs\FigEdit sample demonstrates the implementation of an EditorView that can be open at the same time as the TextEditor. The FigEdit sample is implemented in native code. In the new VS SDK that will be released shortly, there is a new C# managed sample, VisualStudioIntegration\Archive\CS_Samples\SampleDocViewEditor, that also demos the implementation of a designer view that is compatible to be open at the same time as the TextEditor. These samples use the TextBuffer of the TextEditor as the DocData object for the edtior. The EditorFactory of these samples support creating either a "Designer" view or a "Code" (TextEditor) view. I think one of these samples is a reasonable starting point. Also, if you use the "Visual Studio Integration Package" New Project wizard, then one of the choices is to create an editor. This starting point is essentially a re-guided version of the basic editor sample. You can morph it into a VSPackage that supports data/view separation if you need this support.
  
  To answer your question it is a bit difficult without knowing more about your scenario, what language you want to implement in, do you support data/view separation, etc. Generally speaking you will need to convert your Exe implementation into a DLL. For your UI window the easiest thing is to implement IVsWindowPane. Basically you can parent your window's HWND to the DocumentFrame window. On your DocData side you need to decide if you want your editor view to be compatibly open at the same time as the TextEditor. If so, then you should use the TextBuffer as your DocData object. In this case the TextBuffer does much of the hard work for you; you will need to hook up to IVsTextLinesEvents to stay in sync with changes to the text. If you don't require compatibility with the TextEditor, then you will need to implement your own DocData object with IVsPersistDocData and IPersistFileFormat interfaces. Your implementation of IVsPersistDocData is fairly standard and can be identical to the code in the samples. Your custom work of actually loading and saving your file is in your implementation of IPersistFileFormat. If you implement a custom DocData object, then you will also be responsible to call IVsQueryEditQuerySave2 to ask for permission to edit and save your file. If your file is under Source Code Control (SCC) then the user may be asked to check out the file. If SCC says you can not edit the file, then you need to be prepared to role back the edit to the file. See "CanEditFile" method in the BasicEditor sample. Another feature you may want to consider is to hook up for file change notifications and prompt the user to reload the file if it is changed outside of VS. The Archive\BscEdt sample demos doing this (see references to IVsFileChangeEvents in the BscEdt sample).
  
  

• Hamscher

  For an example of a well designed package have a look at the new package reference sample, which can be found at <VS SDK Install Root>\VisualStudioIntegration\Samples\IDE\<CPP|CSharp>\Reference.Package.  This is not an editor, but it is a well designed package.  The other reference samples for menus and commands, services, and tool windows, are also well designed packages.
  
  We do no yet have VSL or MPF support for editors, and we have not yet done reference samples for editors, so samples like basic edit and figures package are the best available samples at the moment.

  
  

• Bmxpert

  Hi Doug,
  This is by far the best clear-cut notes about VSIntegration I've seen in the forum. Thanks for that. It would help me and others to align our theoritical knowledge.
  
  I have a couple of very interesting questions. But first,
  
  Design:
  Got an implementation of a custom editor (I started just the way you recommended using the wizard, selecting an editor.) Once I did that, I conviniently replaced the default richtextbox control with a webbrowser control. Used the IsDirty flag TextChanged event to cater to my webbrowser by raising events from within my in-memory object model. Basically this object model is a deserialized version of an XML document (a XML file with a .xam extension) that I am trying to edit in this webbrowser control. This webbrowser control is placed on top of the EditorPane.
  This webbrowser control displays the XML data in a neat way in tables (I use XSLT here) In the editorpane, I respond to user actions on this html using javascript's window.external.mymethod(); by modifying the object model based on user's actions. On Save, I serialize this back to the XML document.
  So far so good. But,
  There are two things that are lacking and I want to implement them.
  1. I can't manage undo's and redo's. I have no direction how to do this in the design above.
  2. The user cannot do a visual studio Find (ctrl+f) on my custom editor, because its a webbrowser control.
  
  If would be great if you could help me/point me in right direction as to how to achieve the above 2 features.
  Without them, I am sure the user wouldn't like it. Anyone for that matter.
  
  Thanks in advance,
  Vin
  
  
  

• EricaL

  Thanks a lot guys.
  Basically i am trying to build a LUA (a popular open source scripting language: www.lua.org) editor integrated within visual studio. Basically i am trying to add debugging support from within visual studio. The basic debugger providing support for basic debugging steps (watches, current statement etc.) is a C++ dll. An addin uses that debugger dll to provide a minimalistic UI within the IDE which is basically a tool window with a watch window, a couple of buttons for stepping into and out of code etc. etc.
  However, i wanted a properly integrated debugger (i cannot make a stand alone debugger package since its an embedded language and not a standalone language like C++, VB etc., if someone needs more details then i'd be happy to point it out). So i decided to add syntax hi-lighting too, and for that i decided to use an open source edit control (Scintilla : www.scitilla.org) which gives build-in support for LUA. I started by making an intermediate DLL which is essentially a wrapper over scintilla. This DLL alone provides almost complete editing functionality with a scripting interface in which you can define extra keywords and control the look and feel of the hi-lighted code. My standalone editor uses this DLL and this DLL is precisely what my VSPackage will use, so that both editor's have a common core, which can be modified just once to reflect changes in both editors.
  So here i am, trying to make an integrated editor within visual studio. Personally i find it quite absurd when i realize that so many people willing to write their own VSPackages will have to re-implement a plethora of crappy COM interfaces just to get the basic structure going! I think there should be a well designed, basic application built-in within visual studio (perhaps an improved version of basic edit ), because i know that whatever time it takes me to build the entire package, more than half of it will definitely be wasted in understanding and implementing a set of crappy interfaces :(, rather than focussing on the main editor's functionality..
  
  
  

• Klepa

  Unfortunately there is not a simple interface to populate the Watch Window like a list view control. You would need to implement a DebugEngine to do what you want. While it is possible to implement the ideal integrated debugging experience if you implemented a custom DebugEngine, I don't think it is a reasonable approach for you. Unfortunately there is not convenient helper/reference implementation and documentation for this feature to make this simple for you. This is an area that we hope to improve in the future.
  
  In the mean time your custom toolwindow approach may be the most reasonable. As for your editor integration, I really recommend starting by running the "Other Project Types\Extensibility\Visual Studio Integration Package" wizard and pick the choice to implement an Editor. This will give you a good starting point.
  
  
• Custom Editor