Databinding issue

triplea posted on Thursday, November 01, 2007

I am using Winforms and CSLA 2.1.4. I have a textbox which extends the System.Windows.Forms.TextBox and adds some typical functionality when bound to a Csla object. One of them is to set the control as read only if the user cannot edit the property the control is bound to (using of course the CanWriteProperty() method). I noticed that when setting the focus inside the textbox (which currently is set to readonly) and tab out without of course making any changes, data binding tries to update my object. So a security exception is thrown but "absorbed" by databinding, thus locking the focus on the control! So the user is stuck in there and cannot even close the window.
The only workaround I can think of is to change the setter of my property as follows:

From:
set
{
   CanWriteProperty("Name", true);
   if (value == null) value = string.Empty;
   if (_name != value)
   {
      _nam1 = value;
      PropertyHasChanged("Name");
   }
}

To:
set
{
   if (value == null) value = string.Empty;
   if (_name != value)
   {
      CanWriteProperty("Name", true);
      _name = value;
      PropertyHasChanged("Name");
   }
}

But I don't really want to do this... Has anybody had any similar problems or can suggest a solution?

Jimbo replied on Thursday, November 01, 2007

Some suggestions:
1. One would hope that you are using a BindingSource. (.net 2/3 databinding 101)
2. One would hope that for simple controls you have implemented the csla BindingSourceRefresh control. 3. most importantly for the behaviour you are suggesting: In your Databindings.Add statements set the DataSourceUpdateMode to .OnPropertyChanged rather than the default of .OnValidation. (If using the designer to set up your controls then locate and change the options there. but you might want to move the DataBindings.Add code into your form code rather than the designer to avoid loosing your custom settings - avoid the designer as much as possible)

triplea replied on Thursday, November 01, 2007

Thanks Jimbo

1. Yep I am using a BindingSource
2. That's a no... I admit that I just now read about the BindingSourceRefresh and ReadWriteAuthorizer controls which makes me feel dumb. I will definately strip that enabling/disabling functionality from my controls and use ReadWriteAuthorizer.
3. I did try change this but there was no difference. I have seen other forums suggesting this change but at the moment I have left the default .OnValidation. But surely this shouldn't make a difference?

Jimbo replied on Thursday, November 01, 2007

Im not conversent with the ReadWriteAuthorizer control - must be new in 3.

However on point 3 there is a difference when you are using csla style property setters and post validadation rather than pre validation or validation events. This is where we have usually had problems with locking. Besides, the idea in the csla approach is to throw broken rules in combination with the error provider interface so users are not overly inhibited in moving around.

JoeFallon1 replied on Thursday, November 01, 2007

There are various overloads for CanWriteProperty.

Most throw an exception.

I never liked this idea. And apparently now Rocky doesn't either.

I have always suggested using the overload which returns a Boolean and then branching to either return the real value or a dummy value.

Rocky now offers the same suggestion as a best practice.

The dummy value should probably be "" for string fields and 0 for numeric fields.

For example:

        If CanReadProperty("Title") Then
          Return mTitle
        Else
          Return ""
        End If

Joe

RockfordLhotka replied on Thursday, November 01, 2007

That's true for reading. Returning a dummy value is as easy, or easier to debug than throwing an exception, and avoids some runtime issues that appear otherwise unavoidable.

For writing I still favor throwing an exception. Such an exception is a bug, and shouldn't happen at runtime (because you should have prevented the value from being altered by using ReadWriteAuthorizer or something similar).

The alternative with a write would be to simply and silently ignore the attempt to change the value - and that would allow hard-to-debug UI errors to exist. I think the exception is better in that case.