In WPF it is possible to load XAML at runtime and put it in a ContentControl using XamlReader.Load()
Is this possible in Avalonia?
I want to get to a point where I have a user control that contains a content control and based on my configuration, this could point to a file on disk having XAML code to read.
In WPF this works nicely, and the XAML is imported, parsed and the datacontext is inherited, allowing my to put data inside the loaded XAML through my databindings.
I have been searching for an equivalent in Avalonia, but not been successfull.
Install Avalonia.Markup.Xaml.Loader package and use AvaloniaRuntimeXamlLoader class.
Related
In my UWP app, my control options are User Control and Templated Control. My understanding of a User Control is KIND OF clear at this point.
I was told that a Custom Control's style/template is only instantiated in memory once, and that this only happens at the time the control is first used. That's what I want since I know the control I am creating will be used in a ListView.
In the book, XAML Unleashed, however, the author creates his Custom Control by starting with a User Control, and then simply changing it's base class. The thing is that the control he created calls InitializeComponent(). I hear that this type of class uses more memory because it is re-instatiated for each item in the ListView.
Also, I never thought that Custom Controls used the InitializeComponent() method. I thought there was simply a call to this.DefaultStyleKey = typeof(MyClass); in the constructor. What gives? I am confused on what is what...
And last, why is the style/template of the Templated Control placed in the global Generic.xaml file, instead of its own separate file (i.e., xaml file and a code-behind file pair)? If the control is supposed to be custom and "portable", then shouldn't it be totally separate from other code? I haven't found a single article explains any of these things in detail on any level.
This is something most people get wrong so I'll try to clarify a few things for you.
Memory
The whole memory thing, it's all in the Visual Tree. When you instantiate any control, whether templated or UserControl, you will use up memory with every instance because in both cases you are creating a full copy of the visual components in the template.
The templated control will create a copy from the ControlTemplate while the UserControl parses the XAML file when InitializeComponent() is called.
Memory usage will be the same if you create 100 templated controls or 100 user controls if their content is the same.
Usage
Templated controls are best for situations where you're creating a single component, like a Button, Slider, MyStarRatingInput, etc. and you're giving the users of your control the ability to swap out the template with their own. It takes a lot more effort to do this properly than UserControls because the logic has to be template agnostic and your templates have to react properly with visual state changes.
A UserControl is best for layout or views, like forms, popups, screens, pages, etc. You will not give someone the freedom to tamper with the content of your view. You may expose a few public/dependency properties if some views are reusable in a small way, but generally they are set in stone.
Generic.xaml
I honestly don't have an answer for this. Microsoft should've allowed multiple resource dictionaries to enable cleaner partitioning of control templates. Generic.xaml is a reserved filename that referencing projects will look for as the root source of the base styles of your controls. You could reference other XAML files from Generic.xaml, but that's annoying and it bloats the root of your resource dictionary. For now, you're stuck with this method.
Recommendation
If you're sharing a control library, you would want to use templated controls as much as possible. If you're building controls, views, pages, etc for your current project and they're not meant for reuse, then use UserControls.
You can still create a UserControl in your control library if you plan on owning the template and forcing all users to accept your design.
I also recommend templated controls for items that you plan on instantiating a hundred times in a single view, like a ListView. You will see noticeable speed improvement if your template is preloaded into memory instead of parsing a XAML file on every instance.
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.
i only get the exception in the XAML Editor in visual studio 2010, when i debug the application everything works fine and that resource gets loaded successfully, however the problem only happens in the XAML editor, is there a way to disable such exceptions?
<!--ViewModels-->
<!--This View Model Causes the problem-->
<SharedViewModels:DatabaseViewModel x:Key="DatabaseViewModel"/>
and thats how i use it in the main window
DataContext="{Binding Source={StaticResource DatabaseViewModel}}"
This is a known issue as described in Troubleshooting WPF Designer Load Failures in the UserControl and Custom Control Resources at Design Time section:
By default, UserControl and custom control resources that are available at run time may not be available at design time. When you add your custom controls and user controls to a Page or Window on the design surface, an instance of the control is created. Resources in App.xaml are not available to UserControl and custom control instances loaded on a page or window.
To make your resources available at design time, factor them into a separate resource dictionary and include the dictionary in App.xaml and your control's XAML. Change all StaticResource references to DynamicResource references. The following code example shows how to share a resource dictionary so that its resources are available at design time.
So basically in addition to including your resources in App.xaml you also need to include them in your XAML to make them available at design time. In my experience using DynamicResource instead of StaticResource does not seem to be necessary.
I've been trying to find how does the lifecycle of an application with a GUI written in XAML looks like. This blog post really confused me. The quote:
To fully understand the areas of opportunity for improving startup time, it's important to understand the workflow of a launching application.
1. The App constructor is called in App.xaml.cs.
2. XAML in App.xaml is parsed.
3. Application_Launching is called in App.xaml.cs.
4. The Page constructor of your MainPage is called.
5. XAML in your MainPage is parsed.
6. OnNavigatedTo is called in your MainPage.
I though that XAML is compiled to BAML and embedded to dll. Runtime just translates BAML to .Net objects.
Is it different for WP7 Silverlight? Does Runtime parse it like a browser parses HTML?
What is the point of C# files generated from XAML? (e.g. Main.xaml.g.cs) Is it different for C++ and XAML apps?
.g.cs files are auto-generated and contain information related to the general layout of a XAML page. Here is a pretty good description.
The runtime indeed parses the XAML that is embedded in the assembly - unlike WPF, it is not embedded as BAML.
So I am using Silverlight telerik RadScheduler. When creating an appointment using this control an AppointmentDialogWindow pops up. Now, I want to change the look of the window (i.e. its borders, frame etc.)
I am pretty good with Blend but I guess some code - behind will be necessary to set the window style for this Dialog Window.
Any Suggestions?
If you have the full source, go the the specific Theme folder you are looking to implement and grab the SchedulerView.xaml file from there. This is the style file for that specific control.
Reference this resource as a ResourceDictionary in App.xaml or the respective page you will implement the control.
Now when you edit this style sheet it will directly affect how the SchedulerView control operates, including it's child windows.
Warning: this is a cumbersome pain in the neck. Telerik doesn't really like people messing with their styles, and they have acknowledged that they do no typically make it easy for their existing styles to be modified.
Here is how to implement a custom theme:
http://www.telerik.com/help/silverlight/common-styling-apperance-themes-custom-theme-project-telerik-approach.html