I'd like to use the same data at design and runtime in my WP7 application. The relevant part of the XAML looks like this:
<phone:PhoneApplicationPage ...
d:DataContext="{d:DesignData Source=data.xaml}"
DataContext="{Binding Source=???}"
This way I can see the data at design time. Is there a way to use the same data at runtime?
Was not aware of the existence of d:DataContext. I dare to say:
<phone:PhoneApplicationPage ...
d:DataContext="{d:DesignData Source=data.xaml}"
DataContext="{Binding Source=data.xaml}"
--- Edit added -------------------
Well... checking here and there found that, as expected, "DesignData" is not the same as "Binding" (I was misreading this, sorry). "DesignData" has the ability to instance, at design time, an object based on a xml file and this has no effect at runtime. The Binding we are try to build will never work, as its purpose is to use already instanced objects.
When you run the default template for panorama applications it instances its own data (check the code for MainViewModel.cs)... and that's why it shows is different from that in the xml file. All you have to do is, manually, open the xml in the "LoadData" method and load the file data so you can display the same at runtime and design time.
Related
We are developing a Windows10 Universal App (UWP). We have huge issues related to how RelativePanel behave depending of syntax and pc.
We have dynamic data response from a web service and we have to display a dynamic structure of UI controls to render the GUI.
We are trying to use RelativePanels with child elements composed of ItemsControls rendering different type of sub data (Addresses, Phones, etc..).
The ItemTemplate of each ItemsControl' item is a Template composed of a RelativePanel.
Now, the weird stuff happened differently between design and runtime.
At design time, when we want to set Target UIElement of the RelativePanel, we can use the following syntax:
Ex: RelativePanel.Below="EntryMobileNumbers" or
Ex: RelativePanel.Below="{Binding ElementName=EntryMobileNumbers}" />
They are supposed to both work but they don't.
For some RelativePanels’ child elements, if we use the first syntax, the xaml designer bugs and display weird error message
about “value must be of type UIElement”.
Looked on forums for this type of Xaml error and it seems for some developers it’s better to use the second syntax with the Binding.
The good side of it is with that the design is not displaying the squigglys and the error BUT the pb is at Run-time;
the result is wrong and some elements are overlapping.
With syntax 2
With syntax 1
We have also different issues between dev pc’s. With the VS2015 Enterprise installed on all pc’s,
some are displaying squigglys or crash the Xaml Designer with Syntax 1 and some are not.
We also tried to update VS2015 with yesterday’s RC1. It fixed the issues on one of the Pc and not on the others.
PS. All samples out there are very simple. I would very happy to see a "real life" application.
Like e.g. Money from the store to see how layout are managed
RelativePanel.Above="{Binding ElementName=SubTitleDesktop}"
instead of
RelativePanel.Above="SubTitleDesktop"
and it will helps you get rid off errors
In ReactiveUI, I run this code at a certain point:
const string template = "<DataTemplate xmlns='http://schemas.microsoft.com/winfx/2006/xaml/presentation' xmlns:routing='using:ReactiveUI.Routing'>" +
"<routing:ViewModelViewHost ViewModel=\"{Binding}\" VerticalContentAlignment=\"Stretch\" HorizontalContentAlignment=\"Stretch\" IsTabStop=\"False\" />" +
"</DataTemplate>";
var theTemplate = XamlReader.Load(template);
On other platforms, this works great (the xmlns declaration is different of course), but on {WinRT / Metro / Windows Store}, this throws an Unspecified Error:
WinRT information: The type 'ViewModelViewHost' was not found. [Line: 1 Position: 253]
The Twist
However, if you include a dummy resource on the page:
<Page.Resources>
<DataTemplate x:Name="Foo">
<routing:ViewModelViewHost ViewModel="{Binding}" />
</DataTemplate>
</Page.Resources>
...then it works! What gives?
The "twist" makes me think this must be because the application does not have correct XAML metadata for the type being instantiated - rather than using reflection to resolve types in XAML files like WPF/Silverlight, WinRT uses code generation to resolve via the IXamlMetadataProvider interface (there's a decent description here; this sounds like what you're doing, see also the followup). Adding the reference forces this metadata code to be generated properly. If this is the case, you should be able to achieve the same effect by simply adding the type itself to the resources under some unused key, without the data template.
Have a look in your application's "obj" directory, Visual Studio generates a XamlTypeInfo.g.cs file to implement IXamlMetadataProvider. This should contain an entry for the type that is failing - in the case where you have added a dummy reference, there should be full details required to instantiate the type. Without this, I've found it's possible to have some reference to type type, but insufficient information - however this prevents the fallthrough behaviour (looking up the type in a dependent DLL which might have a custom metadata provider).
Other than adding a dummy reference to the library type in the final application itself, the only solution I found for this is to apply the Bindable attribute to the type. While this is supposed to relate to C++, I found this can be used in C# to force a type to always appear in the code generated for XAML type metadata.
For my windows 8 application i am trying to navigate between pages with out using code behind.
For example, i have one image in my UI without creating tapped event for that image i need to navigate to another page,
<Image Source="ms-appx:///Assets/Logo.png" Width="155" Height="110" Tapped="{ // Navigation method here }"/>
Is it possible to navigate between pages like this...? If possible, how can i get this to work??
XAML is just a declarative language without action part so code behind is an essential part of it.
All interactions work via events and event can be handled in a code behind only. So what you want is not possible with XAML(at least with WinRT XAML).
If you are asking if you can specify the code inside the .xaml file, then no, that is not possible.
If you are asking if you can avoid adding code to the .xaml.cs file, then yes, that is possible. You will still need to specify a method but it can even be done as a simple lambda. You will need to use the Command hooks rather than the Event Hooks, e.g.
<Button Command="{Binding GoConnectionCommand}" ... />
The code for this command is usually defined in the ViewModel as part of the MVVM pattern, and Josh Smith explains it far better than I will.
AlSki mentioned using a ViewModel. Although technically the ViewModel is not part of the "code behind" for the XAML file, it's still code and I believe you were asking for a no code solution.
ixSci is correct that there is no way to do this out of the box without code behind in WinRT XAML.
In full WPF it's possible to do this using a behavior called NavigateToScreenAction. You can read about it here. Unfortunately behaviors don't ship out of the box with WinRT, but they can be added back in by an open source project called WinRtBehaviors.
There is no NavigateToScreenAction behavior for WinRT, but one could be created. There is a good article on creating behaviors with the library here. It will obviously require code to create the behavior, but after it's created you could use it in XAML without any code.
Really, the short answer is it's not possible to navigate without code on WinRT.
Dev support, design support and more awesome goodness on the way: http://bit.ly/winappsupport
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.
Hi I'm trying to dynamically load xap files with MEF. I've got some bare bones code working with very basic Silverlight xaps. But loading xaps which are based on MVVM light I get a "Cannot find a Resource with the Name/Key Locator" which I guess is related to the host need something from MVVM Light. Can anyone with this? Cheers, Chris.
The error means that you are missing a resource called "Locator", usually being the ViewModelLocator. Look at your view XAML and you should find something like this:
<... DataContext="{Binding SomeViewModel, Source={StaticResource Locator}}" ...>
This line specifies the data context for an element. The data context is bound to the SomeViewModel property of a the static resource named Locator. Usually the locator is defined in the App.config by a statement similar to this:
<prefix:ViewModelLocatorClassName x:key="Locator"/>
The error most likely means that this line is missing.