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.
Related
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.
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.
Let's say I have ten Apps. I also have a project with an "AboutPage" that downloads feeds from my blog. I don't want to recode or copy & paste that page and it's logic in every project of my Apps; also if I made some update to that page, I would like them to be visible to the other projects.
I think I would need to reference the page into the other projects, but I can I solve the problem of the different namespaces and so on?
Is a good idea making a custom control like a "MyBlogFeedReader" and put it into a page?
We can create a runtime component and move the xaml page into it. Then reference the runtime component into your different projects.
I have a similar runtime component SharedXAML and have a xaml page SharedPage defined in it. In other project, it's so easy to navigate to the page as below:
Frame.Navigate(typeof(SharedXAML.SharedPage));
Short story : can you make 2 XAML to reference into single C# class? If so, how do you add the reference in the XAML?
Long story : I'm currently making an Universal App for 8.1 in VS. After investigating the code-behind, both platform have same codes (identical). So my plan is to put the class for code-behind in the Shared folder, but I still don't know how to make both XAML (Windows 8.1 and WP8.1) to refer to this class as code-behind.
I've read this one : How do you reference a class through xaml?
But this is for WPF, and it specified the class as static
edit : I'm not making the XAML into shared file, since I've designed them platform-specific
You are probably looking for the x:Class attribute of the Page element in XAML
However, it would be better to use two xaml.cs files for each xaml page in the windows store and windows phone projects, and have the common code in a separate class in the Shared Project.
Still better, you could keep all your code in the shared project, and use a single xaml page and single xaml.cs class for both phone and tablet, by using the VisualStateManager. This is what you will have to do when you port your app to Windows 10, which is a truly universal app.
You can probably just put the xaml.cs file in the shared project, or create a third file for the shared code and declare it as partial. Then implement the differences in the projects.
However, if you do this, I think you'll have problems with adding event handlers to the xaml, much as you do if you create a base class and derive from it, as the handlers will be added to the local project, not the shared one.
Try to use code-behind as less as possible. XAML is designed with MVVM in mind, so code-behind should be minimal, ideally empty. Besides MVVM, there're attached behaviors, custom controls etc. which help moving code from code-behind.
If you can't get rid of code-behind completely, use your usual tactics of sharing a common piece of code — just move the code into a separate class, for example, or use class hierarchy.
Note that besides XAML and code-behind, there's a generated file which connects control names to control fields etc., so there's more code than you see. Code-behind relies on this generated code, so it can't be shared within the same project, even if the code is the same.
Just some ideas (may not be perfect):
Add the UI of both controls into one XAML file and then just hide/remove the unnecessary one.
Use a template (custom) control.
Files in the shared project count as part of the other projects that reference the shared project. When you're building the configuration specific project it doesn't matter if a file is in that project directly or if it is in the shared project.
That means that you can leave the .xaml files in the target-specific projects and move the .xaml.cs file to the shared folder.
For Universal Windows apps in Windows 10 it's even easier: the controls will all be the same so you don't need separate code. If you do want to tailor your experience to different devices you don't need a shared project but can use device qualifiers to provide separate xaml files for different targets.
I discuss using partial classes and resource dictionaries to share code in my blog entry Strategies for sharing code in XAML-based Universal apps
In winforms – there's a message pump waiting for an event to happen – when that happens – the appropriate event handler in C# is called.
In WPF there's also XAML. When is that executed? Does the C# code call it or does it call the C# code? In other words: Does an event trigger C# code to run, or does it trigger XAML to be executed?
It seems (please correct me if I'm wrong) that WPF is not really different in the flow of things from winforms. The message pump will call C# event handlers, and the initialization of the form will be done in an InitializeComponent method.
The difference is just that the InitializeComponent method of a WPF form will include parsing an XAML file, so essentially, the developer is describing the initial appearance of the form using XAML instead of C#.
(Of course "C#" can be interchanged here with "VB".)
Here's some info about the wpf application and it's "lifecycle". http://msdn.microsoft.com/en-us/library/ms743714.aspx
And here's some info on InitializeComponent and the role it plays tying into Xaml parsing. What does InitializeComponent() do, and how does it work in WPF?
I'll see if I can find a more official post about the Xaml parsing.
From http://msdn.microsoft.com/en-us/library/aa970678.aspx
"
The XAML file is parsed by the markup compiler.
A compiled representation is created for that XAML and copied to the obj\Release folder.
A CodeDOM representation of a new partial class is created and copied to the obj\Release folder.
In addition, a language-specific code file is generated for every XAML file. For example, for a Page1.xaml page in a Visual Basic project, a Page1.g.vb is generated; for a Page1.xaml page in a C# project, a Page1.g.cs is generated. The ".g" in the file name indicates the file is generated code that has a partial class declaration for the top-level element of the markup file (such as Page or Window). The class is declared with the partial modifier in C# (Extends in Visual Basic) to indicate there is another declaration for the class elsewhere, usually in the code-behind file Page1.xaml.cs.
"
A XAML-Parser parses it and creates the respective CLR objects from it, that is about it.