I use the default WPF ribbon shipped with VS2012 Express.
When RibbonTextBox databound to double property in viewmodel initialised by value 1.75, it displays it and allows modifying numbers around the decimal separator without framing it in red colour as it does when entered non-numeric character such as 'x' etc.
But once decimal separator deleted, there's no way to type it back into the RibbonTextBox. It accepts nonsense characters, but not the decimal separator. In other words, after deleting the decimal separator, it behaves rather as databound to int.
XAML
xmlns:rib="http://schemas.microsoft.com/winfx/2006/xaml/presentation/ribbon"
...
<StackPanel Orientation="Horizontal" HorizontalAlignment="Stretch" >
<Label Content="Source Gamma " />
<rib:RibbonTextBox Text="{Binding SrcGamma, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" Width="50"/>
</StackPanel>
C# code behind
public double SrcGamma { get; set; } // initialised to 1.75d
Note 1: First, I suspected it to be a culture problem. My Windows culture (cs-CZ) uses ',' decimal separator but my application displayed '.' separator.
a) Setting Windows culture separator to '.' didn't help.
b) After overrriding application locale according to this SO question, the correct Windows culture separator is displayed, but cannot be entered either.
Note 2:
During my investigation I added a standard TextBox (outside the ribbon). After adding a custom double validation rule to it, it started behaving just the same way as the RibbonTextBox mentioned.
Thanks in advance for any suggestion.
The answer was hidden in this SO Article.
The strange behaviour was caused by UpdateSourceTrigger=PropertyChanged I used to use in .NET 3.5 where it behaved in an expected way. After removing it, the decimal separator can be added without any problems now.
Well, MS had reasons to do this change, so let's bear it in mind.
Related
I bind single properties to a TextBox without a specific StringFormat with the intension to show the value exactly like the user entered it.
<TextBox x:Name="TBSingleValue" Text="{Binding Path=SingleValue, ValidatesOnDataErrors=True}" />
The current automatic StringFormat creates the following result:
123456789 => 1.234568E+08
0.123456789 => 0.1234568
I need to display the values within -10e-9 and 10e9 without the scientific formating or automatic round.
With a StringFormat:
<TextBox x:Name="TBSingleValue" Text="{Binding Path=SingleValue, ValidatesOnDataErrors=True, StringFormat={}{0:F9}}" />
it parsed as expected but now I get every Decimal place, even when the value doesn't need one.
4 => 4.000000000
So here my Question:
Do you know what kind of StringFormat I should use to display every enteres Decimal place without showing unnessessary ones?
Best case would also a support of , and . as Decimal delimiter.
Edit:
I came up with a quite simple solution:
<TextBox x:Name="TBSingleValue" Text="{Binding Path=SingleValue, ValidatesOnDataErrors=True, StringFormat={}{0:0.###########}}" />
The custom StringFormat character # shows a digit only if one is present. The 0 at the beginning ensures that there is a 0 at the beginning even for numbers of 0.001.
This structure disables the scientific notation and gives the number with the required precision, without unnecessary 0 at the end.
Even -0.00000001 is displayed correct.
I've got the following Situation:
TextBox which is bound to a property:
<TextBox Text="{Binding Settings.ClientName, UpdateSourceTrigger=PropertyChanged}"/>
The property ClientName stores its value in the unterlying structures and does NOT call Notifyon the property changed event. instead the underlying structures send an event to refresh the UI after they processed the value . If such an event is fired, the ClientNameProperty is set correctly and Notify is called for this property.
the problem is that if i enter any text, the caret seems to jump to the first position in the textbox, actuall reversing any string i enter. "abcd" becomes "dcba"
I noticed that this behaviour occured after we migrated to Net 4.0.
Are there any good solutions out there?
Many thanks
There is no built-in behavior that would do that. That problem is likely to come from your processing.
On a side note, if you want the TextBox to change from code-behind as well as from user input, you want to make it Two-Way:
<TextBox Text="{Binding Settings.ClientName, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}"/>
EDIT:
You could also make the ClientName a dependency property (propdp snippet in vs2010). That would automatically fully support binding(/styling/animation), and gives you the possibility to act when the value changes as well as to coerce it back through callback delegates.
Last but not least, you still wouldn't need your Settings class to implement INotifyPropertyChanged.
Here is a place to start (msdn).
I suspect you are suffering from this behavior change in the WPF TextBox: https://connect.microsoft.com/VisualStudio/feedback/details/588343/changed-behaviour-from-net-3-5-to-net-4-0-of-wpf-textbox-formatting-when-propertychanged-is-used-as-updatesourcetrigger (Changed behaviour from .Net 3.5 to .Net 4.0 of WPF TextBox formatting when PropertyChanged is used as UpdateSourceTrigger)
Here's my code snippet :
<TextBox Text="{Binding Path=Amount, Mode=TwoWay, StringFormat=\{0:N\}}" />
If the user enters letters or a large number etc, the stringformat dies silently. How can i raise an exception instead ?
Thanks
Bindings swallow exceptions thrown when text input cannot be converted to the data type required by the property on source object. However you can specify ValidatesOnException in the binding. That will cause the standard red border reporting of a conversion problem. BTW this is unrelated to the string format property which is only relevant for displaying the current value, it isn't in play when user is entering data.
<TextBox Text="{Binding Path=Amount, Mode=TwoWay, StringFormat=\{0:N\}, ValidatesOnExceptions=True}" HorizontalAlignment="Left" Width="200"/>
Note I've limited the width and aligned to left. One of the problems with the default validation popup is that is that it is always displayed to the right, which is a bit of a problem when the text box right border is flush with the right edge of the silverlight control's right edge.
Have you thought of writing a filter behavior that allows you to control exactly what goes into the text box?
I dislike WPF's inability to interpret text in a case-insensitive way.
Are there any tools (i.e. VS plugins) out there that will take my VB .NET code and handle the case-sensitivity issues for me?
Edit: Now with examples.
Input:
<Dockpanel DockPanel.Dock="Bottom">
<Label Content="(c) blahblah" HorizontalAlignment="Left" Name="Label2" VerticalAlignment="Bottom" Opacity=".75" Background="White" DockPanel.Dock="bottom"/>
</DockPanel>
Output:
<DockPanel DockPanel.Dock="Bottom">
<Label Content="(c) blahblah" HorizontalAlignment="Left" Name="Label2" VerticalAlignment="Bottom" Opacity=".75" Background="White" DockPanel.Dock="Bottom"/>
</DockPanel>
This is kind of like trying to use C# without ; or XAML without angle brackets. Case sensitivity is an intrinsic part of the XAML language and the WPF Binding system. If your VB code is causing problems when you're using it with WPF turn Option Strict on and fix the inconsistent casing in your code.
I don't think that WPF is the problem here.
If you need to validate data and remove case from the problem, then convert all your strings to Upper or Lower before comparing.
If you need to change the way that a TextBox functions in WPF, either create your own inherited TextBox and override the Text property or modify the setters in your bound properties to modify any value it receives such as
public string Name
{
get { return this._name; }
set
{
this._name = value.ToUpper();
OnPropertyChanged("Name");
}
}
Without more information about the problem, I am not sure what else to suggest.
I'm not exactly sure what you're trying to achieve, but I ran into case sensitivity issues when checking usernames. Our standard is SimpsonHJ, but some users would log into their machines as simpsonhj or SIMPSONHJ. So I made a variable that changes the username found to all uppercase
private string un = Environment.UserName.ToUpper();
easy and simple
If you have to compare two strings.
One can be stored in list, string or is some variable, other string is inputted by user on text box.
Then simply use To Upper or To Lower
These will convert the string first into upper or lower case just for compair_values.
Ex.
string s = "ram" ;
string p = "Ram" ;
if(s.ToUpper()==p.ToUpper())
{
Console.WriteLine("String matched");
MessageBox.Show("String matched");
}
else
{
Console.WriteLine("Not matched");
MessageBox.Show("Not matched");
}
Try it, you will get your answer
I am using WPF 4.0 TextBox and binding. I am using StringFormat to format the number as currency. the XAML looks like this:
<TextBox Text="{Binding Path=ValueProperty, ValidatesOnDataErrors=True, ValidatesOnExceptions=True, StringFormat={}{0:C}, UpdateSourceTrigger=PropertyChanged}">
</TextBox>
Everything seems to work correctly except for a strange behavior:
When for example a user types in 12: right after typing 1, the value in the textbox becomes $1.00 and the weird thing is the the cursor is moved to be between the $ and the 1.
So when a user simply types in 12, the result becomes $21.00.
How can I fix this strange behavior?
I'd change your UpdateSourceTrigger back to the default (for TextBox) of LostFocus.
By setting it to PropertyChanged, you're forcing your validation, and the string format, to run every time the user types a character. This causes very odd behavior, such as what you're seeing.
If you leave it the default (or set it back to LostFocus explicitly), the formatting + validation will happen when the user finishes typing completely. This will eliminate the strange problems that happen by StringFormat inserting new characters, validation breaking part way through, and other issues you will run into using PropertyChanged.
you can use this string format it'll fix this issue
"$###\,##0.0##"
your code should looks like
<TextBox Text="{Binding Path=ValueProperty, ValidatesOnDataErrors=True, ValidatesOnExceptions=True, StringFormat=$###\,##0.0##, UpdateSourceTrigger=PropertyChanged}">
</TextBox>
This issue has been fixed in .NET 4.5. For .NET 4, I had to remove StringFormat in order to keep UpdateSourceTrigger=PropertyChanged