In CSLA 4 an exception is thrown when you attempt to add an object to a BLB and that object isn't a child. That's good, in that it enforces an important rule.
However, it causes issues with the WPF datagrid control, which has no hook where you can create a new object when the user hits the last row. The *(#$@ datagrid insists on creating the new object and adding it to the underlying collection.
Of course that triggers this exception.
So I am considering a change to this behavior. Instead of throwing an exception, BLB could call MarkAsChild() on the new "child" object. Basically force the object to be a child.
The advantage to this is that it would fix this WPF datagrid problem.
The disadvantage to this is that it could basically hide a bug. You might construct an object as a root, and add it to a BLB, and it would become a child - possibly causing confusion.
However, I suspect that this advantage outweighs the disadvantage.
But I wanted to open it for discussion. What do you think?
I assume "Get Microsoft to fix the *(#$@ WPF DataGrid" isn't an option...
From my perspective, I don't see much other choice. As crappy as the WPF DataGrid is, not being able to use CSLA collections with it is a problem. While I understand the issue with hiding a potential programming bug, you could also look at it a different way. A CSLA collection requires that all its children are marked as such, so why make the consumer remember to do it? It's an ironclad convention, so maybe it's better to code that directly into the framework.
- Scott
Hi Rocky,
Since Pre-Release 4.0.0-100108, BusinessListBase inherits from ObservableCollection<T> and exists to integrate "nicely" with WPF.
My questions are:
1) Do we also need to use it (instead of BusinessBindingListBase) with Silverligh 4?
If the answer is yes, then comes the next question:
2) Does this problem also exists with Silverlight 4 Toolkit DataGrid?
If the answer is also yes, I'd say go ahead with the change. Microsoft most probably will never fix this issue and it will became a feature we must live with.
You can use BLB or BBLB in WPF. In fact you have to choose the right base class to work with your UI controls, since apparently some third party datagrid controls don't work well with ObservableCollection (to my amazement!).
Silverlight does have a "BBLB" type, but it is actually just BLB. It exists purely for serialization compatibility, not to provide behavioral equivalence, since Silverlight isn't "contaminated" with all the old Windows Forms stuff.
The WPF datagrid from Microsoft does not behave the same as the SL datagrid. The SL datagrid is generally more mature. However, it doesn't have the ability to automatically add new rows, and so avoids this issue.
Hi Rocky,
Hiding a bug doesn't seem a good choice but having a useless application seems to be also a bad choice.
If we have the source for WPF DataGrid, a modified control can be made available in CslaContrib.
If we can't change the source and given the complexity you described, we might be better with both worlds.
I think you could also argue that automatically making the object a child is a feature - that it isn't hiding a bug at all. Rather, that you shouldn't have to worry about details like setting the object as a child, and that CSLA should just make that work for you.
Hi Rocky,
Did you made a decision on this issue?
Sorry, this slipped through the cracks. I've now added it to the wish list.
Can this be solved at the control level (like Jaans did with ComboBoxEx for Silverlight)?
You can certainly try. When I looked at the problem originally I did take a quick look at the events on the datagrid control and didn't see a way to override the default behavior. Most datagrid controls do have a way to override this behavior though, so perhaps I just missed it...
Copyright (c) Marimer LLC