We're working on creating a specialized graphical editor for our enterprise applications. We've looked at and rejected DSLs. Ideally I'd like to have the main interface of the editor be docked like the code windows and use WPF for drawing. Can anyone point me to some documentation to get me on the right path?
Thanks.
Colin.
UPDATE: It's beginning to look like "no." From http://msdn.microsoft.com/en-us/library/bb166228.aspx: "Document windows are created by implementing an editor. The IVsEditorFactory interface creates document windows as part of instantiating an editor. For more information, see Accessing the Editor By Using Legacy Interfaces."
Following the link to http://msdn.microsoft.com/en-us/library/dd885127.aspx gives this this bit of advice: "You can access the Visual Studio editor from legacy interfaces. The Visual Studio SDK includes adapters known as shims, which enable these interfaces to interact with the new editor. Nevertheless, we recommend that you update your legacy code to use the new editor API. Your code will perform better and you can use new technologies such as the Windows Presentation Foundation (WPF) and the Managed Extensibility Framework (MEF)."
So, to sum up: if you want to implement an editor you have to use the legacy interfaces, but you shouldn't use the legacy interfaces because then you can't use WPF or MEF.
Seriously Microsoft, WTF?
UPDATE 2: Now that I have the proper names ("custom editor"), I was able to find the following topic: http://social.msdn.microsoft.com/Forums/en-US/vsxprerelease/thread/9e605d0f-1296-47c9-a534-e54905251ebe
I still don't see why they couldn't have included that somewhere prominent in the MSDN docs. You know, like somewhere near where they tell you that you can't use WPF if you're using the legacy interfaces.
Creating a custom editor doesn't have to be terribly painful. Yes, a custom editor will require implementing a few interfaces, but you can still use WPF to actually create the control that is hosted in the VS document frame.
DiveDeeper's blog has some great resources for learning about creating a custom editor.
Creating a simple custom editor - the basics
Creating a simple custom editor - the first 10 meters
Creating a simple custom editor - under pressure
I'd recommend using a library like VSXtra to do a lot of the work for you. It will provide you with a nice base implementation of an editor factory, editor pane, package, etc. Istvan Novak writes about building a custom editor with his VSXtra library in this blog post.
Related
I am building a Visual Studio extension (VSIX) with menu commands depending on the options for the extension. Its dynamic, what commands (how many) depends on the options.
I have a solution for it that uses the command-table, like: Dynamically add menu items
I would like to skip the command-table and build the menus totally programmatically, like: HOWTO: Package with commands created by code
The reason is to make it more dynamic. So if the user adds/changes/deletes in the options of the extension it would be handled dynamically (programmatically). On saving options the menu-command tree would be rebuildt. If I use a command-table I will have to add/delete nodes there to be able to solve it.
The thing I can not figure out is howto add the objects for "groups" and "menus" programmatically.
So I am out for the class/interface that has "AddGroup" or "AddMenu" as methods.
Is this at all possible or do I have to use the command-table? If it is possible I would appreciate links to code-examples for it.
Regards Hans
MVP Carlos Quintero has published sample code using IVsProfferCommmands3.AddNamedCommand that illustrates how to programmatically add menu items via the automation services (formerly utilized by the now discontinued add-in extensibility model).
https://github.com/visualstudioextensibility/VSX-Samples/tree/master/PackageCommandsCreatedByCode
While add-ins are no longer supported, the automation interfaces are still present. So you can use these, bearing in mind these menu items (aka commands) are temporary.
Also, the sample code here is a little outdated, using Package instead of AsyncPackage, and ProvideAutoLoad attributes. So you'll also want to read up on the following:
https://github.com/microsoft/VSSDK-Extensibility-Samples/tree/master/AsyncPackageMigration
https://devblogs.microsoft.com/visualstudio/updates-to-synchronous-autoload-of-extensions-in-visual-studio-2019/
Sincerely,
I have a C++/winrt project with a complex and dynamic xaml interface created in C++ code. Now I am moving to the latest VS 15.9.0 Preview 3, which has platform support for C++/Winrt and also allows use of the xaml designer in such a project. But I don't want to use the designer and have turned it off in Tools/Options/Xaml. The result is that none of my programmatic xaml elements appears. The project seems to expect me to enter these elements in a xaml code page, rather than using C++, e.g. Grid(), StackPanel(), view.RowDefinitions.Append(), view.SetRow() etc. The GeneratedFiles folder is now full of items that were not present in the previous project, yet can't be removed. Is it still possible to use the C++ interface for xaml, and what must be done to enable it if so? Thanks.
Ryan is correct: C++/winrt does support programmatic creation of xaml, and it works great. With the help of a couple of c++/winrt guys at MS I think I also know why my code was not doing anything. In the former version of my app I had declared MainPage as a C++ class, not a struct, and had assigned the starting Grid for the xaml by getting the current Window and setting currentWindow.Content(theGrid). But in the new template app MainPage is a struct, which might matter, and while setting window.Content that way no longer works, this does: this->Content(theGrid). Leaving aside some irrelevant issues about declarations in the BlankApp, this I think is the answer. Programmatic xaml works if you set that initial content as above.
Unfortunately, this is not the intended way to use this UI system. XAML-based UI systems are descendants of WPF, which relies on the Model-View-ViewModel (MVVM) pattern.
This pattern intends three types of classes to make up your application: Views, which are primarily written in XAML, and only deal with displaying data they are given; ViewModels, which are the wrapper and translator to give the views data, and to give the models commands; and lastly, Models, which are your backend business-logic classes.
Your instinct to not trust the designer is reasonable - it generates messy and unidiomatic XAML code. But it is an excellent way to preview the way your XAML code looks.
To get back to your specific situation, there are real problems in the library's API that will be serious roadblocks to programmatically define a UI in C++. Instead, you will want to use XAML to declare the UI. Adding and removing grid column definitions is not something that is well-supported, but using StackPanels and DockPanels is the normal way to do this.
If you have more specific questions, feel free to open a new question here, but do bear in mind that you may want to search first under the tags mvvm and wpf in addition to xaml, c++-winrt, and winrt.
If you have more questions that are rather broad and may be too broad for the main site here, feel free to join the WPF channel on chat, but bear in mind that most of us don't have experience in WinRT specifically.
I'm writing a lot of peoplecode in Oracle's Peoplesoft Application Designer 8.53
as far as IDE's go its pretty rudimentary but i'd like to be able to apply a custom Highlighting Scheme or customize the automatic white space manipulation that happens on save.
i found a few registry keys that allowed some customization but is anyone aware of a more complete list of possible registry modifications to customize the app designer text editor?
e.g. the examples i have found so far include
"PeoplecodeText"="Text,0,16777215,1,1"
"PeoplecodeTextSelection"="Text Selection,0,65280,0,0"
"PeoplecodeNumber"="Number,16512,16777215,0,1"
"PeoplecodeOperator"="Operator,32896,16777215,0,1"
"PeoplecodeComment"="Comment,10789024,16777215,0,1"
"PeoplecodeQuotedString"="QuotedString,255,16777215,0,1"
"PeoplecodeKeyword"="Keyword,16744448,16777215,0,1"
"PeoplecodeClassDefn"="ClassDefn,8421376,16777215,0,1"
"PeoplecodeBuiltin"="Builtin,8388736,16777215,0,1"
Just a quick question: When talking in terms of an IDE, what is a property editor?
You're probably hearing about the Properties Window in Visual Studio that allows you to change the properties exposed by a control at Design Time.
It looks something like this (at least, if you're kickin it old school), but generally you'll find it implemented as a grid-based window in all IDEs:
Otherwise, you're probably talking about a custom class that inherits from UITypeEditor and allows you to add design-time support to a custom control that you've created. It works in conjunction with the Properties Window shown above to add additional functionality that is relevant to the specific needs of your custom control. This is discussed in detail in this CodeProject article.
I've seen lots of MEF code for plugging into custom apps, but I am yet to find out how to write a plugin for VS2010 using MEF. I was under the impression that the new IDE supported this.
Does anyone know if this is supported 'out of the box', or does it require an install. Does anyone have any links, tips, etc to get me started.
MEF is the primary extension mechanism for extending the editor. If you install the SDK, there are a few new project samples set up to create editor extensions, found under C# (or VB)->Extensibility. These include:
Editor classifier – for providing syntax highlighting
Editor margin – putting a margin along the sides of the editor, with arbitrary WPF content
Editor text/viewport adornment – for putting WPF visuals into the editor
You can find overview documentation on MSDN: Extending the editor, and Editor extension points.
Some samples you may want to look at: editor samples on code.msdn.microsoft.com, a couple more on editorsamples.codeplex.com, and the source for all the samples I've written.
I blog about writing editor extensions. On there, you can find descriptions of most of the extensions I've written, along with more general posts about performance, design of the new editor, etc.
Questions posted on the editor forum on msdn also are answered by various members of the editor team.