I have found that in a very specific situation, changing text in a TextBox does not update the underlying datasource when using data binding. If you set a property to either null or String.Empty twice in a row, then you enter a 1 character value in the
text box, the binding does not fire. Below is the code to reproduce.
In this code if have a "Person" class which stores a first and last name. I have implemented the INotifyPropertyChanged interface and made the FirstName and LastName properties bindable. I have put FirstName and LastName textboxes on my Silverlight form
and bound those textboxes to an instance of the class. On this form I have a button which sets the two properties to null and another that sets the two properties to String.Empty. There is also a multi-line textbox which displays a message any time the FirstName
property is set. This fires normally if you change the first name (and tab) or click one of the two buttons.
Here is how to reproduce the issue. Run the app, then click the "Set Null" button one time. Change the text of the First Name text box to a single character and press tab. You'll see that the change message properly fires. Now click the "Set Null" button
twice in a row, then change the First Name text box to a single character and press tab. This time the change message won't fire.
It will fire properly if you enter text that is more than one character long. You can also get the error to reproduce if you set the property to String.Empty twice in a row (or null then empty or empty then null). This issue appeared after upgrading to
RC0.
This will be a real issue for my application. I am writing a data entry application where the user can scroll through records and update data. For example, if the user is scrolling through names and two people in a row don't have middle initials, then
on the third name the user enters a one character initial, then the data won't be saved properly.
I'm having a very simular problem where basically after a dialog I created gets into a certain state all of a sudden all the text boxes require multiple key presses before they will update their bindings.
My problem however doesn't seem to involve setting the properties to null or to string.empty, clicking a button twice does seem to be common though.
Have you had any success with fixing the problem? This too also only happened to me once I'd upgraded from the beta 2.
Did you find anyway around this? I am seeing the same problem in the RTM version. Basically once a get on a textbox is called 3 times with a null or empty string the databinding stops firing for one letter entries in the textbox.
I have been working at try to eliminate the multiple calls to the getter, but it is tricky. So, I'd really like to know if there is a fix for this issue?
Unfortunately, no. I was hoping the problem would go away with the official release, but that did not happen. I've got some time before my application is released so I am now hoping for a hot fix or service pack to fix this. If that does not happen, I'm
going to have to code some sort of work around as this bug would be a show stopper in my application.
Thanks. Have you gotten any confirmation from the product team that they acknowledge the bug?
In testing today, I find that is bigger than just applying to empty and null strings. If i have an actual value, and run the getter 3 times due to background property changes. Then change 1 letter either adding one or removing one. The binding does not
trigger.
This is also a huge showstopper for me. I am trying to avoid calling the getter multiple times, but having trouble with the way our property notification architecture is put together.
Thanks for reporting this issue. I'm able to repro the above sample code with SL2 RTW. Can you please elaborate on the end to end scenario that is blocked by this?
Are you asking under what scenario a user would experience this bug? An example is an app where the user enters/edits names. If the user looks at two names in a row that does not have a middle initial, then on the 3rd name, adds a middle initial, then
that change would not be recognized.
For me, I was able to come up with a workaround. My problem was that I had some code that was firing PropertyChangeNotification for a form several times without knowing whether the values in the textboxes actually changed. The problem occurs when I load
different customers and they have the same value, like empty string. After the third propertychanged notification. The first character typed stops executing the binding.
I was able to put some code in that stored the value of each textbox in a private member variable when it is retrieved in the get. Then only fire property changed for those textboxes that are actually different.
So, not a show stopper for me anymore. But, was a huge pain in the neck to figure out the specific problem and code the workaround.
nelson5000
0 Points
4 Posts
DataBinding Bug - TextBox change does not update binding
Oct 09, 2008 07:04 PM | LINK
I have found that in a very specific situation, changing text in a TextBox does not update the underlying datasource when using data binding. If you set a property to either null or String.Empty twice in a row, then you enter a 1 character value in the text box, the binding does not fire. Below is the code to reproduce.
In this code if have a "Person" class which stores a first and last name. I have implemented the INotifyPropertyChanged interface and made the FirstName and LastName properties bindable. I have put FirstName and LastName textboxes on my Silverlight form and bound those textboxes to an instance of the class. On this form I have a button which sets the two properties to null and another that sets the two properties to String.Empty. There is also a multi-line textbox which displays a message any time the FirstName property is set. This fires normally if you change the first name (and tab) or click one of the two buttons.
Here is how to reproduce the issue. Run the app, then click the "Set Null" button one time. Change the text of the First Name text box to a single character and press tab. You'll see that the change message properly fires. Now click the "Set Null" button twice in a row, then change the First Name text box to a single character and press tab. This time the change message won't fire.
It will fire properly if you enter text that is more than one character long. You can also get the error to reproduce if you set the property to String.Empty twice in a row (or null then empty or empty then null). This issue appeared after upgrading to RC0.
This will be a real issue for my application. I am writing a data entry application where the user can scroll through records and update data. For example, if the user is scrolling through names and two people in a row don't have middle initials, then on the third name the user enters a one character initial, then the data won't be saved properly.
XAML:<
UserControl x:Class="BindIssue.Page" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Width="400" Height="300"> <Canvas x:Name="LayoutRoot" Background="BlanchedAlmond"> <TextBlock x:Name="lblFirst" Canvas.Left="0" Canvas.Top="0" Text="First"></TextBlock> <TextBlock x:Name="lblLast" Canvas.Left="150" Canvas.Top="0" Text="Last"></TextBlock> <TextBox x:Name="tbFirst" Canvas.Left="0" Canvas.Top="20" Width="140"></TextBox> <TextBox x:Name="tbLast" Canvas.Left="150" Canvas.Top="20" Width="140"></TextBox> <Button x:Name="btnSetNull" Canvas.Left="0" Canvas.Top="50" Width="100" Height="30" Content="Set Null" Click="btnSetNull_Click"></Button> <Button x:Name="btnSetEmpty" Canvas.Left="150" Canvas.Top="50" Width="100" Height="30" Content="Set Empty" Click="btnSetEmpty_Click"></Button> <TextBlock x:Name="lblMessage" Canvas.Left="0" Canvas.Top="90" Text="Messages"></TextBlock> <TextBox x:Name="tbMessage" Canvas.Left="0" Canvas.Top="110" Width="400" Height="160"></TextBox> </Canvas></
UserControl>Code:
drssilverlight
Member
4 Points
2 Posts
Re: DataBinding Bug - TextBox change does not update binding
Oct 16, 2008 09:00 AM | LINK
I'm having a very simular problem where basically after a dialog I created gets into a certain state all of a sudden all the text boxes require multiple key presses before they will update their bindings.
My problem however doesn't seem to involve setting the properties to null or to string.empty, clicking a button twice does seem to be common though.
Have you had any success with fixing the problem? This too also only happened to me once I'd upgraded from the beta 2.
rpowers119
Member
8 Points
4 Posts
Re: DataBinding Bug - TextBox change does not update binding
Oct 31, 2008 02:13 PM | LINK
Did you find anyway around this? I am seeing the same problem in the RTM version. Basically once a get on a textbox is called 3 times with a null or empty string the databinding stops firing for one letter entries in the textbox.
I have been working at try to eliminate the multiple calls to the getter, but it is tricky. So, I'd really like to know if there is a fix for this issue?
nelson5000
0 Points
4 Posts
Re: DataBinding Bug - TextBox change does not update binding
Oct 31, 2008 02:51 PM | LINK
Unfortunately, no. I was hoping the problem would go away with the official release, but that did not happen. I've got some time before my application is released so I am now hoping for a hot fix or service pack to fix this. If that does not happen, I'm going to have to code some sort of work around as this bug would be a show stopper in my application.
rpowers119
Member
8 Points
4 Posts
Re: DataBinding Bug - TextBox change does not update binding
Oct 31, 2008 03:50 PM | LINK
Thanks. Have you gotten any confirmation from the product team that they acknowledge the bug?
In testing today, I find that is bigger than just applying to empty and null strings. If i have an actual value, and run the getter 3 times due to background property changes. Then change 1 letter either adding one or removing one. The binding does not trigger.
This is also a huge showstopper for me. I am trying to avoid calling the getter multiple times, but having trouble with the way our property notification architecture is put together.
nelson5000
0 Points
4 Posts
Re: DataBinding Bug - TextBox change does not update binding
Oct 31, 2008 07:01 PM | LINK
No, I have not taken any actions on this bug other than to post it here on this forum.
emikelsoft
Member
8 Points
5 Posts
Re: DataBinding Bug - TextBox change does not update binding
Nov 07, 2008 03:03 PM | LINK
We have exactly the same probleme!
A fix for this problem is very important for each real datacentric app.
A comment from MS would be nice.
ifpx895
Member
78 Points
16 Posts
Microsoft
Re: DataBinding Bug - TextBox change does not update binding
Nov 20, 2008 01:08 AM | LINK
Thanks for reporting this issue. I'm able to repro the above sample code with SL2 RTW. Can you please elaborate on the end to end scenario that is blocked by this?
Thanks,
nelson5000
0 Points
4 Posts
Re: DataBinding Bug - TextBox change does not update binding
Nov 20, 2008 04:05 PM | LINK
Are you asking under what scenario a user would experience this bug? An example is an app where the user enters/edits names. If the user looks at two names in a row that does not have a middle initial, then on the 3rd name, adds a middle initial, then that change would not be recognized.
rpowers119
Member
8 Points
4 Posts
Re: DataBinding Bug - TextBox change does not update binding
Nov 20, 2008 04:13 PM | LINK
For me, I was able to come up with a workaround. My problem was that I had some code that was firing PropertyChangeNotification for a form several times without knowing whether the values in the textboxes actually changed. The problem occurs when I load different customers and they have the same value, like empty string. After the third propertychanged notification. The first character typed stops executing the binding.
I was able to put some code in that stored the value of each textbox in a private member variable when it is retrieved in the get. Then only fire property changed for those textboxes that are actually different.
So, not a show stopper for me anymore. But, was a huge pain in the neck to figure out the specific problem and code the workaround.