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.
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.
Often, when I'm looking for information of how to set certain properties of controls (I'm using Visual Studio primarily, but this question does apply to any IDE), the examples I find normally involve programatically setting said properties.
Here's an example, using the DataGridView.DefaultCellStyle property on MSDN:
http://msdn.microsoft.com/en-us/library/system.windows.forms.datagridview.defaultcellstyle(v=vs.110).aspx
So my question is: is it better for a programmer to modify these properties by code, or is it better to use the IDE itself to change them via the properties pane? I realize that doing it the latter way will result in auto-generated code anyway, but it will be "somewhere else" in relation to the main bulk of user-generated code.
It depends on your requirements. If the app you are developing is planned to be dynamic, then it is a good idea to do it the way it is described in the reference you provided. For example, you may create a class containing the method which will set the basic settings of the gridview, so on every page you may just call this method and pass to it the gridview as a parameter instead of repeating setting the grid properties on every page.
Visual Studio allows you to design components visually. For example, you are designing a Windows form. You change its property in the properties editor. The IDE will generate the code in a partial class in xx.designer.cs file. We can customize this behavior by changing the UITypeEditor for the properties.
The question now is: Can we extend this code generation behavior? For example, we change a setting in the property window, and then the IDE will add a .NET attribute to the class?
To my knowledge, that is not possible. Sorry. Such a thing IS possible with Eclipse, however, because it's open source.
Can You tell me about subj?
For example I need to create new custom control that must be derived from datagrid and toolbar. And I want that new control to expose/propagate properties of base controls in order they to be accessed easily. The only way I know is deriving a class. Then descendant automatically gets all properties of ancestor. But multiple deriving in C# is prohibited, so I don't know how to expose properties and other behavior of second control... Styling and templating of such custom control is also needed.
Thanks!
In WPF inheritance is "out". ;O) Actually, it was complicated before WPF already, but with WPF you get various really powerful alternatives.
For the basic control I thing you'd better go with composition, create some usercontrol and make it contain a ToolBar and a DataGrid. You can then expose these as public properties, if you need to manipulate them from outside.
For special feature additions, attached properties are a very versatile mechanism.
Watching a window from windowsclient.net is a good place to start.
Make sure you understand dependency properties well.
Reading wpf blogs is my best guest for what to do then.