Bug in databinding?

Bug in databinding?

Old forum URL: forums.lhotka.net/forums/t/1354.aspx


JonM posted on Thursday, September 28, 2006

I am databinding to standard textboxes (using CSLA 1.5x and VB.net 2.0).  Depending on the rules inside of the object some properties will not actually be changed (like if the user does not have permission).  Normally, what happens is as they type, their changes are ignored and the old value is put back in the textbox.  However, if I use formatting in my databinding this does not happen!  While the value is still read-only and does not get changed in the business object, the UI continues to show whatever the user typed in.  Below is the code I'm using to databind.

As you can see I'm binding to a field and setting the formatstring to 'c' so that it formats as currency.  If a turn off the formatting everything works great (expect that the decimal value is not formatted like money).  Any ideas on this?  Surely someone else has seen this??

txtQtyPrice.DataBindings.Add("Text", _po.LineItems(polineitemID), "QtyPrice", True)

txtQtyPrice.DataBindings(0).FormatString = "c"

txtQtyPrice.DataBindings(0).DataSourceUpdateMode = DataSourceUpdateMode.OnPropertyChanged

 

ajj3085 replied on Thursday, September 28, 2006

You may want to move to Csla 2, since it supports the 'new' databinding, and .Net 2 databinding is much improved over the way Csla 1.5 forces you to go.

JonM replied on Thursday, September 28, 2006

Well there is a small problem with that.  This project was more than 80% complete when CSLA.net 2.0 was released.  It's a little bit difficult to justify moving over to an unknown platform when we were nearly complete.  Also, we implemented our system using the examples from the original book with the CheckRules("") business rule pattern.  Moving to CSLA.net 2.0 would mean rewriting and testing the validation rules for 150+ objects.  This is something a little hard to cost justify when the existing codebase works very well (expect for a few minor issues, like the one I've described).   However, we do look forward to testing the new CSLA on a smaller project and then eventually converting this one to it. 

RockfordLhotka replied on Friday, September 29, 2006

JonM:

Normally, what happens is as they type, their changes are ignored and the old value is put back in the textbox.



How do you implement this behavior? In the object or in the UI?

JonM replied on Friday, September 29, 2006

It is done in object.  Basically the object checks to see if the user has permission before it changes the internal value for the property.  If they do not, nothing happens.  When I do not format the value the value is instantly changed back to the original value if the user does not have permission.  However, if I use formatting, then whatever they type in stays in the control even though the value is not being changed in the underlying object.  It is very odd.

RockfordLhotka replied on Friday, September 29, 2006

Are you using the bindingsource extender control I created in Chapter 5? Without that, you wouldn't get a refresh of the data value for the property just edited - data binding has that "optimization" that gets in the way of normal PropertyChanged event processing.
 
Well, also, are you raising PropertyChanged in the property set even though you are blocking the change? If you don't raise PropertyChanged, then data binding wouldn't be triggered to refresh the value at all - it just assumes that the value on the form is correct.
 
Rocky


From: JonM [mailto:cslanet@lhotka.net]
Sent: Friday, September 29, 2006 5:49 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Bug in databinding?

It is done in object.  Basically the object checks to see if the user has permission before it changes the internal value for the property.  If they do not, nothing happens.  When I do not format the value the value is instantly changed back to the original value if the user does not have permission.  However, if I use formatting, then whatever they type in stays in the control even though the value is not being changed in the underlying object.  It is very odd.


Copyright (c) Marimer LLC