You can define custom Dictionaries in XAML in the following way.
// *.cs
public class MyDictionary : Dictionary<string, int> { }
// *.xaml
<sys:Int32 x:Key="Zero">0</sys:Int32>
But what about other Key-Types? You can use the extended element usage in XAML 2009:
<object>
<x:Key>keyObject</x:Key>
</object>
However, this isn't supported in Silverlight yet.
Is there anything I can do? I want to use a custom Dictionary with System.Type as Key-Type.
Silverlight does not support generics in XAML. You also can't create an arbitrary typed object directly because SL would not know how to instantiate it.
You should consider Chris Haines's suggestion of having your dictionary as a view model because it's better practice to have such things be defined outside of xaml.
You can't really do this in Silverlight (see Is there any way to instantiate a 'Type' in Silverlight XAML?)
You could wrap your dictionary and input strings and let it convert them to types internally, but REALLY, why can't you just use the string representation of Types? Do Type.FullName
Related
I'm just getting started with MVVMCross, so forgive me if this seems like a simple question. I'm trying use the MVVMCross Visibility plugin in WPF, mentioned here:
https://github.com/MvvmCross/MvvmCross/wiki/Value-Converters
I installed the plugin, and am trying to follow these steps:
Windows - use Native wrappers or Tibet Binding as described above:
Visibility="{Binding VMProperty, Converter={StaticResource
Visibility}}"
When I try to do so, it can't find the resource "Visibility."
So I figured, I can add the namespace:
xmlns:visibility="clr-namespace:Cirrious.MvvmCross.Plugins.Visibility;assembly=Cirrious.MvvmCross.Plugins.Visibility"
...and then add the converter to my resources:
<visibility:MvxVisibilityValueConverter x:Key="Visibility"></visibility:MvxVisibilityValueConverter>
...but now I get:
An object of the type "Cirrious.MvvmCross.Plugins.Visibility.MvxVisibilityValueConverter" cannot be applied to a property that expects the type "System.Windows.Data.IValueConverter".
Do I have to make my own Converter for this, like this:
class MyVisibilityConverter : MvxNativeValueConverter<MvxVisibilityValueConverter>
{
}
...or am I missing something? The docs seem to indicate there's less work involved.
IValueConverter isn't currently a portable interface, and this was a deliberate decision from Microsoft. I've talked to one of the guys from the PCL team about this - he seemed very clear that they expected most value converters to be platform specific and so not to sit in shared code.
Because of this - and because MvvmCross believes many value converters will be shared - we had to introduce our own IMvxValueConverter interface inside MvvmCross. This IMvx interface can't be used directly by XAML and the Microsoft bindings - so that's the reason you need the "native" wrapping currently.
You can work around this - if you want to - by using the MvvmCross "Tibet" binding framework instead of the Microsoft one, but I think most MS-based devs are still using the MS-binding.
am I missing something? The docs seem to indicate there's less work involved.
For using value converters on Windows, the wiki says the text below - if you think this can be improved, please do contribute changes back - we're keen to keep on improving.
Using Value Converters in Windows (conventional Xaml binding)
The IMvxValueConverter interface is closely based on the IValueConverter interface used in Windows WPF and Silverlight Xaml binding. This interface is also similar (but slightly different) to the IValueConverter interface used in Windows WinRT Xaml binding.
Because these Xaml IValueConverter interfaces are not 100% identical to each other, nor to the IMvxValueConverter version, shared Mvx ValueConverters cannot be used directly in Windows Xaml binding - they must instead be wrapped for use in Xaml.
The steps to do this are similar on each Windows platform:
for each IMvxValueConverter class, e.g. for
public class TheTruthValueConverter
: MvxValueConverter<bool, string>
{
public string Convert(bool value, Type targetType, CultureInfo cultureInfo, object parameter)
{
return value ? "Yay" : "Nay";
}
}
in your UI project, create a 'native' wrapper using the MvxNativeValueConverter class:
public class TheNativeTruthValueConverter
: MvxNativeValueConverter<TheTruthValueConverter>
{
}
in your Xaml, include an instance of your ValueConverter as a static resource - this can be done in the Resources at App, Page or Control Xaml level, e.g.:
<converters:TheNativeTruthValueConverter x:Key="TheTruth" />
now your converter can be used - e.g.:
<TextBlock Text="{Binding HasAccepted, Converter={StaticResource TheTruth}}" />
Using Value Converters in Windows (Tibet binding)
In addition to 'traditional' Xaml bindings, MvvmCross also allows 'Tibet' binding within Windows - for more on this see wiki/Databinding.
When Tibet binding is used, then Value Converters can be accessed by name - exactly as in Droid and Touch binding - without the above native Xaml wrapping.
Further, if using 'Tibet' binding then an entire assembly's worth of value converters can be registered using the Reflection sweep technique and this can be specified at the Xaml level - meaning it can be used in both design and run-time.
To include all value converters within an Assembly at the Xaml level, then use an mvx:Import block with an inner From attribute which contains an instance of a class from that Assembly.
This may sound complicated… but actually it is quite simple.
Suppose you have an Assembly MyTools containing FooValueConverter, BarValueConverter, etc
Within this Assembly add a simple, instanciable public Class which we will use only for the import - e.g. public class MarkerClass {}
Then within the xaml, you can include a static resource import block like:
<mvx:Import x:Key="MvxAssemblyImport0">
<mvx:Import.From>
<myTools:MarkerClass />
<mvx:Import.From>
</mvx:Import>
After this is done, then the ValueConverters Foo and Bar will be available for use within 'Tibet' bindings - e.g. as:
<TextBlock mvx:Bi.nd="Text Foo(Name)" />
I have a BaseView for my MVP - PRISM WPF application. Now for some reason we thought to make the _presenter as a Templated field in the BaseView.
earlier i had the view xaml representation as
<base:BaseView xamlns:base="clr address of the dll which had BaseView" >
</base:BaseView>
now since i have changed the BaseView to BaseView<TPresenter>, So how shall i write the Xaml then?
You can do it since .NET 4 Framework and XAML 2009.
See Generics in XAML on MSDN
For instance:
<my:BusinessObject x:TypeArguments="x:String,x:Int32"/>
For .NET 3.5:
For XAML 2006 usage when specifically targeting WPF, x:Class must also
be provided on the same element as x:TypeArguments, and that element
must be the root element in a XAML document. The root element must map
to a generic type with at least one type argument. An example is
PageFunction.
Possible workarounds to support generic usages include defining a
custom markup extension that can return generic types, or providing a
wrapping class definition that derives from a generic type but
flattens the generic constraint in its own class definition.
In case this happens to someone. I had a similar scenario where I converted my base class to a templated class (i.e. BaseView to BaseView). I kept receiving errors in the InitializeComponent() method. I was receiving the null exception error in the x:Class base type's InitializeComponent() call. I was able to resolve the errors by removing the form-level events from the XAML definition. If I had to keep the form-level events I would need to move them to BaseView.
If I have a control and I start typing a foreground property for it, it offers me a list of Colors, seemingly from the Colors class.
edit: I think it's actually the KnownColor enum, which is internal.
How is this achieved?
I have an attached property which is of type MyClass. I have a static class with some pre-cooked instances of MyClass. I want to achieve the same behavior described above.
I know I can use a type converter and convert from the string to an instance, but this seems a little more advanced
You will need to use a Type converter. The Xaml parser has built-in special handling of known types such as Brush and Color.
I want to make a reusable WPF Window suitable for different types T.
I have a designer and a codebehind file.
can I do something like this?
/* Code behind file */
public partial class MyWindows<T> : Window
{}
Shamelessly copied from here (and thus not tested)
public class ViewBase<T> : Window, IView where T : class, IViewModel
{
public virtual T Model
{
get { return DataContext as T; }
set { DataContext = value; }
}
}
and XAML
<src:ViewBase
x:Class="View"
x:TypeArguments="src:IViewModel"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:src="clr-namespace:MyNamespace"
Height="480" Width="640">
...
</src:ViewBase>
Unfortunately, what you want isn't quite possible.
Update: Before .NET 4.0 (i.e. when this answer was originally written), XAML support for consuming generic types was very limited; e.g. generics only worked on the root element. In .NET 4.0, some restrictions were lifted.
In .NET 4.0, you can construct a fully specialized generic type. So while XAML itself still has no concept of generic types, it can refer to specializations of generic types. (By analogy, XAML can't express the notion List<> but it can express the notion List<int>). For full details, see the MSDN page "Generics in XAML".
You can construct instances of specialized generic types with the x:TypeArguments Directive. For example, with x bound to XAML's namespace, sys to the System namespace, and scg to System.Collections.Generic, and your own MyWindows' namespace bound to my then:
<my:MyWindows x:TypeArguments="x:String"> would construct a MyWindows<string> instance.
<scg:List x:TypeArguments="sys:Tuple(sys:String,sys:Int32)"> would construct a List<Tuple<string,int>>
Using generic types is therefore no longer a problem in XAML!
Alas, you want to define a generic type in XAML. That's not possible. There are two workarounds here. Firstly (and based on your comments on another question I think this is what you want) you can simple pass a type as a plain parameter. If you do this, you lose all the compile-time safety features that generics provide, but often enough those aren't relevant. Secondly, you can define a normal non-generic class with codebehind in XAML, and simply use a generic base class for code reuse. That way you get at least some proper generics safety and reuse.
How does the XAML Parser convert the string "Red" in Foreground="Red" to a SolidColorBrush? Allthough I know the Types have System.ComponentModel.TypeConverter defined, I doupt that the WPF XAML parser acutally always uses those to convert the string to the brush. Are there any XAML APIs apart from XamlReader.Load (wich wants a valid xml string) that I could use to parse a single string as if it where an attibute for a certain property?
The XAML parser (for WPF) really does actually use the type converter of the property or property type specified. There are a few hard-coded short-cuts but they are for performance and do not change the semantics. A parser, just using attribute information, can duplicate the parser semantics (which is, for example, what Blend and Cider do).
There is no API that will convert a value exactly as XAML would mainly because many type converts only work in the context of a XAML parse. For example, type converters can refer to namespaces defined in the XAML file (which changes depending on where the value is in the XML file) as well as other ambient information base URI base for the file. These are only really applicable when the XAML file is being parsed.
The closest you can come to is asking for the property descriptor for the property from the type descriptor and using the Converter property. This will scan the appropriate attributes to create the correct type converter.
I believe you can take advantage of this yourself. XamlReader knows the target type (the type of the property to which the string must be applied). You would register a TypeConverter for that property's type.
EDIT this will work for you when it comes to SolidColorBrush:
var colorString = ...;
var converter = new System.Windows.Media.BrushConverter();
var brush = (SolidColorBrush)converter.ConvertFromString(colorString);
Looking at SolidColorBrush in .NET Reflector, it seems the magic that does deserialization within XamlReader uses internal APIs around known types. I'm not sure whether you can register your own types to handle this.