Perhaps it is something trivial but I am out of ideas...
Originally I wanted to add some features to PasswordBox. Because it is a sealed class, original properties have to be replicated, among them PasswordChar. Looks trivial, but when I started to set PasswordChar in Xaml, I could not get rid of parser exception.
At the end I simply defined a new property
public char MyProperty {get; set; }
and tried to set it in Xaml as follows:
<MyPasswordBox MaxLength="3" Password="xxx" MyProperty="c" />
I am getting an exception with the call stack looking like
at MS.Internal.XcpImports.CheckHResult()
at MS.Internal.XcpImports.ConvertStringToTypedCValue()
at MS.Internal.SilverlightTypeConverter.ConvertFrom()
at MS.Internal.FrameworkCallbacks.ConvertValueToPropertyType()
....
at MS.Internal.FrameworkCallbacks.SetValueToProperty()
at MS.Internal.FrameworkCallbacks.SetPropertyAttribute()
....
at System.Windows.Application.LoadComponent()
....
As far I can read it, the type conversion string -> char fails.
Note that whenever I'll change the type of MyProperty to string (for example), everything works.
Does anybody know how to implement char properties so that they can be set from Xaml?
Working on Windows Phone 7, perhaps that's the problem. (Limited SVL 3)
I can't verify this will work, but you can give it a go. The long form xaml syntax should work ok.
Add the following to your namespace imports
xmlns:sys="clr-namespace:System;assembly=mscorlib"
Then the following should work
<MyPasswordBox MaxLength="3" Password="xxx">
<MyPasswordBox.MyProperty>
<sys:Char>c</sys:Char>
</MyPasswordBox.MyProperty>
</MyPasswordBox>
The other solution is to look into type converters to apply to your property so that it'll convert the string for you. Type Convereters and XAML.
Related
No way to explain this issue except by example:
Say you have a custom UserControl with two DependencyPropertys, StatList Stats and string ImportantStat. The job of the user control is to display a table showing all of the values in Stats but with special visual treatment (like a pie chart) of the ImportantStat.
My instinct was to write a block of XAML that looked more or less like:
<PieChart Value="{Binding Path={Binding ImportantStat} }"/>
where the DataContext is prior set to Stats. So, the user passes in ImportantStat = "WinPercentage" and the pie chart binds to the WinPercentage Property of the stat line. But the user can just as easily pick some other Property to emphasize.
The problem (of course, you already know this, educated Stacker) is that you get an error message stating that you can't convert from Binding to string, which is what the outer Binding expects for Path. Though I haven't proven it to myself, I am guessing this is simply because Path is not a DependencyProperty.
So, is there any way to achieve my goal here? Feel free to break my assumptions in that first paragraph. Maybe, for example, ImportantStat can't be a string but must itself be a Binding.
Edit: Attempt #1 Failed
I was hoping that exposing from the code-behind a new DependencyProperty Binding ImportantStatBinding would allow me to rewrite the XAML as:
<PieChart Value="{Binding ImportantStatBinding, RelativeSource=... }"/>
...but to no avail. The indirect Binding is just stuck into Value itself with no attempts to resolve it.
My backup solution, which might be where this is headed, will be to just create the content inside the code-behind where I have access to ImportantStat directly and so can get away with a single Binding.
Far as I know, there is no way to concatenate data bindings in this way, without additional code. To put the problem more simply, we can have data binding (of course) of the form:
A --> B --> C
but you cannot have data binding of the form:
A --> B --> *A (*A indicates the target depends on the value of A)
because the relationships must be fixed.
It seems like it might be possible to create a Converter whose job is to convert a string into an arbitrary value by actually dereferencing a Binding using some additional context and that string as the property path. That sounds messy with type issues, so I chose the only other way I could think of:
I added a new DependencyProperty for the PieChart to the code behind and made sure that I constructed it at the appropriate times, so that the XAML could consume it. It's ugly, but it works. I just feel a little dead inside :) Hope someone finds this useful some day.
I've seen a lot of other ObjectDataProvider questions where the Parameter name: type, name, whatever, cannot be null. Those questions are all due to actual parameters not being set. As far as I can tell, there is no "pattern" parameter for an ObjectDataProvider. The following markup produces "Value cannot be null. Parameter name: pattern", with the accompanying blue squiggle underline. Occasionally the designer throws an exception and fails to load, however pressing the reload button loads the page. The code and markup compile and run as expected. What is causing this?
<Page.Resources>
...
<ObjectDataProvider ObjectType="{x:Type local:AutoFillBox}" MethodName="RecUpdateOutput" x:Key="odpOutput">
<ObjectDataProvider.MethodParameters>
<sys:String>08:00</sys:String>
<sys:String>12:00</sys:String>
<sys:String>13:00</sys:String>
<sys:String>18:00</sys:String>
</ObjectDataProvider.MethodParameters>
</ObjectDataProvider>
</Page.Resources>
Part of the class, wanted to note this is not a custom control, just a poor naming choice:
public partial class AutoFillBox
{
public AutoFillBox()
{ //default }
public string RecUpdateOutput(string time1, string time2, string time3, string time4)
{
//do stuff
}
}
It's the only ObjectDataProvider on the page, and if I remove the 4th string parameter the error goes away. Additionally, the method it calls does take 4 strings, and returns a string so I can bind it's result to an output textbox. I use a similar ObjectDataProvider on a different page with a similar method and signature, and it also shows the same error. What the heck is going on here?
Visual Studio Ultimate 2013, Windows 7 Professional, targeting .net 4.5
I don't believe it's a VS bug. Try adding the property IsAsynchronous="True" to the ObjectDataProvider and that should eliminate the designer error. The property defaults to False and the designer will try to create the object in the active context. Here's link:
ObjectDataProvider
Worked for me. Hope it works for you.
Scenario
I have a class which looks something like this:
class GlobalAssemblyInfo
{
public const string AssemblyName = "MyAppName";
}
The class is NOT contained in a namespace.
I tried unsuccessfully to bind to this using the following code:
Text="{Binding GlobalAssemblyInfo.AssemblyName}"
Question
Is this possible, and if so, how would I accomplish this?
Why I Need This
Before I get any comments about only using bindings for dynamically changing content, let me explain why I need this.
I am creating an app which may need to undergo a rename due to trademark issues. I need to use the name in several places, such as "MyApp Contributors" or "MyApp Help." Using a binding would enable me to say merely Text="{Binding AppName, StringFormat='{}{0} Contributors'}".
You have two problems here. The first is that the way you're using the class in the binding is assigning it to the Path so it is looking for a property named GlobalAssemblyInfo on whatever your DataContext is. You instead need to use a static source and also expose the value as a property instead of a const. This uses the form:
{Binding Source={x:Static ns:Class.StaticProperty}}
The other problem is that you have no namespace to create your xmlns from in XAML. You should consider if you really need the class to not be namespaced but if you do you should be able to use the weird construction of
xmlns:myGlobal="clr-namespace:;assembly="
where you would then use myGlobal in the place of ns in the first example.
If you created a class that has no namespace, why don't you just put your assembly name in Resources in XAML or Resources in project so you can do binding in it with StringFormat
In your App.xaml.
Define something like this
<x:String x:Key="AssemblyName">Your Value</x:String>
or add a new resource file in your project and define it there.
So you can use it something like this
Text="{Binding Source={StaticResource AssemblyName}, Path=., StringFormat="{}}"
I've started creating a Windows Store App for Windows 8.1 and now I encountered a problem concerning localization.
I would like to display a string resource from a .resw file at design time, but every attempt to do so has failed, even though it works at runtime.
When using the x:Uid attribute, I still have to supply the Text property (i.e. for a TextBlock) and I don't like to write the text twice.
I also tried creating a property for the string on the viewmodel:
public string Title
{
get { return ResourceLoader.GetForCurrentView("Strings").GetString("MainView_Title"); }
}
This is working at runtime, but at design time it is blank.
So the question is, is there a way to display resources from a .resw file in the XAML-designer?
More specifically, does the ResourceManager class allow .resw files to be read at design time?
Thanks for your help,
Lucas
Old Method
So, there are a couple of things you can do.
The first (and simplest, given that you're using x:Uid already) is to just supply the text into the Text field. The x:Uid-related value will overwrite whatever is in there.
<TextBlock Text="MyText" x:Uid="MainView_Title"/>
The second method is to use the property like you already have, and then check to see if the app is in Design Time (through a couple of different methods), then return a constant value if it is and the Resource if it is not.
public string Title
{
if(ViewModelBase.IsInDesignTimeStatic) //Mvvm Light's easy accessor
return "My Text";
return ResourceLoader.GetForCurrentView("Strings").GetString("MainView_Title");
}
Hope this helps and happy coding!
Edit: There appears to be a new way to do this, at least as of Windows 8.1.
New Method
Create a class which references a ResourceLoader (similar to the property described above).
Create an indexed property accessor which accepts a string key and return the value from the ResourceLoader.
public class LocalizedStrings
{
public string this[string key]
{
get
{
return App.ResourceLoader.GetForViewIndependentUse().GetString(key);
}
}
}
In your App.xaml, define a StaticResource of this type.
<Application.Resources>
<ResourceDictionary>
<common:LocalizedStrings x:Key="Localized"/>
</ResourceDictionary>
</Application.Resources>
Now, when you want to access your property with entry key MainView_Title, use this. It's more verbose, but it should translate both in the designer and in the app itself.
<TextBlock Text="{Binding Source={StaticResource Localized}, Path=[MainView_Title]}" />
You can shuffle it around to be a bit more readable if you'd like, such as:
<TextBlock Text="{Binding [MainView_Title], Source={StaticResource Localized}}" />
This is an old thread, but since Nate provided such an elegant solution to the problem for Win8.1 I figured I'd ask here...
After much investigation and experimentation, Nate's solution does not appear to work for UWP apps for Win10 under VS2017 Community. The LocalizedString approach works just fine at runtime, but it appears
App.ResourceLoader.GetForViewIndependentUse().GetString(key);
refuses to return anything except String.Empty during design time. I've done a lot of experimenting and things like
ResourceContext.GetForViewIndependentUse().QualifierValues
Seem to be identical between runtime (working) and design time (not working).
I was wondering if anyone has encountered this and solved it. Nate? :)
For a C# UserControl on Windows Mobile (though please answer if you know it for full Windows...it might work) how do you change what shows up in the Designer Properties window for one of the Control's public Properties. For example:
private Color blah = Color.Black;
public Color Blah
{
get { return this.blah; }
set { this.blah = value; }
}
This shows up for the control, but it's in the "Misc" category and has no description or default value. I've tried using the settings in System.ComponentModel like "DesignerCategory", such as:
[DesignerCategory("Custom")]
But says this is only valid for class declarations... could've sworn it was the System.ComponentModel items I used before...
Update:
#John said:
DesignerCatogy is used to say if the
class is a form, component etc.
Try this:
[Category("Custom")]
Is there a particular namespace I need to use in order to get those?
I've tried those exactly and the compiler doesn't recognize them.
In .NETCF all I seem to have available from System.ComponentModel is:
DataObject,
DataObjectMethod,
DefaultValue,
DesignerCategory,
DesignTimeVisible,
EditorBrowsable
The only one it doesn't scream at is EditorBrowsable
DesignerCategory is used to say if the class is a form, component etc.
For full windows the attribute you want is:
[System.ComponentModel.Category("Custom")]
and for the description you can use [System.ComponentModel.Description("This is the description")]
To use both together:
[System.ComponentModel.Category("Custom"),System.ComponentModel.Description("This is the description")]
However this is part of system.dll which may be different for windows mobile.
Is this of use to you? I am not into CF development, but it looks like you need to add some XML metadata to enable it:
http://blogs.msdn.com/bluecollar/archive/2007/02/08/adding-compact-framework-design-time-attributes-or-more-fun-with-textboxes.aspx
Interesting read.. Looks like a lot of design time support was stripped out of CF because you dont design them on the devices.. Which seems kinda weird to me.. Cant imagine using a handheld as a development rig!
Scroll down about half way for the good stuff ;)
The article does not suggest that anyone is designing ON the device. However, when you create a Compact Framework project, the compact framework (for your desktop PC) is used to handle design time rendering. If you think about it that is what you expect. The same framework (or nearly so) is used to do the rendering both on your PC at design time and later on the device at runtime. The issue is that the design time attributes were not added to the compact framework (I assume to reduce the size).