I'm working in Visual Studio 2012 with xaml to create an application. When I make a new solution and WPF project and look at the xaml in the application file, I see xmlns, a startupuri, and a tag for application.resources.
When I want to see the code-behind that these tags are creating, I have only the .cs file with maybe a few things in it and the mysterious InitializeComponent() that performs all of the parsing. Here's an example of what it looks like:
public partial class MainWindow : Window //This is generated with a wpf project.
{
public MainWindow()
{
InitializeComponent();
}
}
If possible, how can I view the procedurally generated code that InitializeComponent is creating?
I don't think that the complete xaml source gets compiled into .g.cs files.
Quoting this codeproject article:
When you compile a WPF application in Visual Studio it will compile your XAML files into a compressed representation known as Binary Application Markup Language (BAML). The BAML is then saved as a resource in the resultant assembly. When that assembly is loaded and the resource is requested, the BAML is streamed out and very quickly turned into the object graph described by the original XAML.
In the project directory, under the obj and Debug folders should be files labeled .g.cs that correspond to existing files. Presumably, these are Generated C-Sharp files that contain the generated code that I was looking for.
Related
Using the
DevExpress Assembly Deployment Tool
helps finding out the needed dll's depending on your references. In my case I have as a reference just DevExpress.Xpf.Charts.v16.1.
The total amount of dll's to deploy from DevExpress is 33. From those, 20 are DevExpress.Xpf.Themes.XXX related.
I understand that depending on the context you can have different themes, like aero, metro, win xp...
Is there any way to reduce the amount of dll's in the deploy folder.
Or
Is there any way to 'fix'/'hardcore' the theme to be used and have just one of them deployed?
Refer this DevExpress Thread - Could not load file or assembly DevExpress.Xpf.Themes...
Starting with version 16.1, the default application theme is "Office2016White". Thus, it is required to add a reference to the DevExpress.Xpf.Themes.Office2016White.v16.1 assembly in your project if it uses the default theme.
In addition, the default theme is now applied to standard WPF controls, not only DevExpress ones.
To switch to another theme, use the ApplicationThemeHelper.ApplicationThemeName property. The DevExpress.Xpf.ThemeManager.ApplicationThemeName property has become obsolete.
To restore the old behavior, set the DevExpress.Xpf.Core.ApplicationThemeHelper.UseLegacyDefaultTheme property to true before the first reference to the DevExpress.Xpf.Core.v16.1 assembly. See the example below:
public partial class App : Application {
public App() {
ApplicationThemeHelper.UseLegacyDefaultTheme = true;
}
}
The value of the static Theme.Default property has been changed to Office2016White.
For the answer of you question, You can just add that theme assembly which your added controls use. If you have changed theme from different control by modifying some properties then you have to be careful about that required assemblies.
Hope this help..
I am building a universal class library with Xaml Views that need to statically reference custom resources (StaticResource) defined inside the same class library.
How can i do that in a designer friendly way without importing the resource file inside every view?
Using VS2013 Update 3. It seems that the designer works only for views inside the specific universal app projects and when the resources are defined inside App.xaml without merging.
I am writing a win8 application and will be using the built-in resource management system: resw file and x:Uid tags in my XAML code.
So I create let's say a TextBox like that:
<TextBlock Style="{StaticResource HeaderTextStyle}" x:Uid="ResourceTest"/>
I create the corresponding resource file in my assembly with a ResourceTest.Text entry and it works fine: proper text is displayed at runtime.
Now, I would like to move all my resx files to another C# Library for maintainability. So I put the resources file in a brand new project and reference this new assembly from the main assembly.
But this causes the previous construct to fail (no text is displayed).
However, if I programmatically retrieve the resource value using the following code from inside the side assembly (called ResourcesLibrary), I get the string correctly:
static ResourceLoader resourceLoader = null;
public static string GetString(string resourceName)
{
if (resourceLoader == null)
resourceLoader = new ResourceLoader ("ResourcesLibrary/Resources");
return resourceLoader.GetString (resourceName);
}
How do I enable the x:Uid mechanism when dealing with out-of-assembly resources?
I tried a few things in the x:Uid such as ResourcesLibrary/Resources/ResourceTest but with no luck.
I had the same problem for a long time. But after testing a little bit, I solved it by writing the whole Path of the Resources in the XAML Code.
Something like this:
<TextBlock x:Uid="/ResourcesLibrary/Resources/ResourceTest" />
Unfortunately this answer came very late, but may it can help other persons.
As per my understanding you can't use x:Uid if the resources are maintained in a .resx file.
if you use .resw files you can access the strings whatever the assembly they are residing in.
they can be accessed as you mentioned in your question like this "ResourcesLibrary/Resources/ResourceTest"
When creating UserControls, it looks like the XAML is being parsed every time the control is initialized.
For example, when I create a UserControl, there's auto-generated code to initialize the component that looks like this:
public void InitializeComponent()
{
if (_contentLoaded)
return;
_contentLoaded = true;
global::Windows.UI.Xaml.Application.LoadComponent(this, new global::System.Uri("ms-appx:///Views/MyView.xaml"), global::Windows.UI.Xaml.Controls.Primitives.ComponentResourceLocation.Application);
}
This existed in Silverlight as well.
Creating the control once or twice is not a big deal, but if I have a large visual tree in each UserControl with Visual-States and bindings, and I'm creating it many times per application lifecycle, it would make sense to build the visual controls using C# to boost performance.
So, my question is:
Does the parser/framework "remember" the XAML file and avoid re-parsing it again on subsequent calls? That is, does it create a binary representation of the XAML so it doesn't have to read text all over again?
It's my understanding that XAML gets compiled into a binary form as a resource within your application. The runtime does not have to parse the text of the .xaml file, just as it does not have to parse your .cs code files.
The performance of instantiating the classes as declared with XAML is supposed to be on par with creating it in code.
Windows 8.1 xaml finally added XAML binary format :)
XAML Binary Format: The final signed appx will no longer contain text based markup as it will get converted into Binary.
How can I use the ResourceDictionary resource from the same DLL?
Basically I am trying to create a UI library with all classes derived from Page class. I want to keep all user interface pages in the same DLL.
To see the problem, from VS2012, create a Windows 8 library project, then add the Item Detailed Page. Now, if you open the created page from the editor, you will get some errors like "The resource "LayoutRootStyle" could not be resolved".
This is just a Xaml Designer error, so that will not prevent your project from building or running .
The only thing needed is that all the ResourceDictonary need to be referenced by the main application App.xaml (for example by using <ResourceDictionary Source="/<myLibraryName>/Common/StandardStyles.xaml"/> or by creating calling an Init method in the Library which will dynamically add the Resource dictionary).
A quick workaround for the error in the Xaml Designer is to just copy an App.xaml/App.xaml.cs in your library (but at runtime the main application will still need to have a reference on the needed ResourceDictionary since the App.xaml of the library will not be used).
Another posibility is to just add a refrence on the ResourceDictionary on each page but I believe that will be much more costly since it will create an instance of the dictionary for each page.