In my project I have noticed that bound controls in winforms is not behaving as they should. I'm shure I had this working before.
In the book the following sequence is described:
1.User edits a value in bound control.
2.Data binding puts the user's new value into the business object
3.The business object alters the value in the property set block.
4.The business object raises its PropertyChanged event.
In my project the value in the bound control is still what the user entered and not the new value altered by the business object.
I'm on csla version 3.8.2
Can someone confirm this?
Are you using the BindingSourceRefresh component? This is a well known Windows Forms issue (they tell me it is a feature), and CSLA 2.0 (or maybe this was even in 1.x) and higher includes the BindingSourceRefresh control that provides a workaround.
Are you using the BindingSourceRefresh component? This is a well known Windows Forms issue (they tell me it is a feature), and CSLA 2.0 (or maybe this was even in 1.x) and higher includes the BindingSourceRefresh control that provides a workaround.
Yes, I have dropped the BindingSourceRefresh control on the form. And I am sertain that it was working before.
I have done some research. I have created a dead simple csla business class to test the behaviour.
I tested on some csla versions I had on my system just by deleting and adding reference to the csla.dll.
2.x Working
3.0.2 Working
3.6.1 Not working
3.8.2 Not working
I think the BindingSourceRefresh control must have broken somwhere between 3.0.2 and 3.6.1
TESTCODE:
Public Property Testverdi() As String Get CanReadProperty("Testverdi", True) Return _Testverdi End Get Set(ByVal value As String) If Not _Testverdi.Equals(value) Then CanWriteProperty("Testverdi", True) _Testverdi = value + 1 PropertyHasChanged("Testverdi") End If End Set End Property
Hi,
The BindingSourceRefresh depends on a custom DesignerAttribute to supply a setting for Host ("container") in the <form>.Designer.cs file. Without the Host property set, the BSR control is unable to attach itself to the containers DataBinding events and will not do anything useful.
I have sometimes experienced that Visual Studio Forms Designer is failing to generate this setting - and this often happens when upgrading to a newer version of CSLA.
Further - the DesignerAttribute is not included in the .NET 4 Client Profile so I have rewritten the BSR to attach itself to DataBinding events on the BindingSources rathert han the Form/Containers DataBindings collection for CSLA 4. So, the new BSR in CSLA 4 does not depend on having the Host property set. The Host property still exists but does nothing (just for backward compatibility.
So:
1. Check that the BSR.Host is set in <form>.Designer.cs.
2. And check that you have the same CSLA assembly version (if registered) in VS Toolbox and in your project.
3. Alternatively - grab the BindingSourceRefresh.cs from Csla4 preview and replace into the CSLA version you are using.
Thanks Jonny,
BSR.Host was not present in <form>.Designer.vb. Adding it solved the problem.
In prior versions of CSLA there was no Host property on BSR. So that explains why it was missing. So, if you are upgrading to a newer version of CSLA you need to add BSR.Host. The host property must have been introduced between 3.0.2 and 3.6.1 somewhere.
Thanks again.
Normal 0 21 false false false NO-BOK X-NONE X-NONE MicrosoftInternetExplorer4
Hi Jonny,
Since you are working on the BSR control. I noticed a change in behavior between the two versions we are talking about. The old version could also handle if you threw an exception inside the setter of a property.
Public Property Testverdi() As String
Get
CanReadProperty("Testverdi", True)
Return _Testverdi
End Get
Set(ByVal value As String)
If Not _Testverdi.Equals(value) Then
CanWriteProperty("Testverdi", True)
If value = "44" Then
Throw New Exception("do not ever use 44")
End If
_Testverdi = value
PropertyHasChanged("Testverdi")
End If
End Set
End Property
The value of the textbox control would go back to the previous value. In the new version it will not. This can cause situations where the user is stuck on the textbox control if the user cannot remember a valid value.
I haven't checked CSLA 4, so this may already have been fixed.
Thanks
Regards,
Wilfred
Hi Wilfred,
This is not changed in CSLA 4 but could possible be done by adding by a new property "RefreshOnException" or always Reread (as the previous sode did)
That change was submitted to CVS repository on January 19 2008 but I do not know why that change was made.
Yes, at least a property "RefreshOnException" vould be nice. It has my vote.
Copyright (c) Marimer LLC