Hello everyone...
We are trying to make a brand new project based on Rockford's CSLA 2.0 framework. While we study the possibilities of the framework we encountered the following issue:
When using a CSLA child collection bind to a DataGridView, we see in the Project Tracker example that a button is used for adding a new row. We have tried to use the DataGridView capability for adding new rows itself. Since the binding mechanism tries to create a new object itself and our child constructor is private an exception occurs. We could not override or even shadow the method called from the binding infrastructure.
Any idea?
Should we always provide a button for using the factory methods for creating the child objects?
Thanks in advance.
Not sure whether my remark is relevant or not … but we have had problems with exceptions caused by controls trying to add an item to the bound collection.
***
There is a known issue with binding grids (particularly Infragistics UltraGrid, but probably, other grids as well) to empty collections:
when such a grid is bound to an empty collection it (temporarily) adds a row to discover what the column headings should be; that results in adding an object to the collection. Later the row and the object are removed, but the collection remains dirty. Thanks to its hierarchical capabilities, the grid changes IsDirty not only on the given collection, but on collections of children (and perhaps grandchildren, and so on). See more here: http://www.searchcsla.com/Details.aspx?msn_id=17162 , http://www.searchcsla.com/Details.aspx?msn_id=17603 .
In .Net 1.1 one of possible workarounds was to introduce a pair of methods (in our implementation they were called AllowNewItem() and DisallowNewItem()) in the collection class, which manipulated the AllowNew flag (the .NET 1.1 data binding infrastructure does not attempt adding new items to the collection if AllowNew = false).
But a few days ago we tried to convert an app that uses that workaround to .Net 2.0 (we simply ran the conversion wizard, we did not port the app to CSLA 2.0) and encountered a problem. It looks like the .Net 2.0 data binding infrastructure does not check the AllowNew flag any more and tries to add a new item regardless; if the flag is set to false (and this is how the flag is initialised) the CSLA BindableCollectionBase class throws an exception. Our tests showed that some of those exceptions were handled by the data binding infrastructure, but some were not; we were not sure which and why. It was possible to get rid of many of the exceptions by calling the AllowNewItem() method on the collection, but we still had an exception caused by a read-only subcollection in the item object.
ajj3085,
you wrote: "setting AllowNew to false shouldn't allow the adding of a new row"
It should not, and it did not with .Net 1.1. It looks to me like the .Net 2.0 data binding infrastructure ignores the AllowNew flag and tries adding an item regardless; possibly, that was a conscious decision on MS’ part: this way data binding is more forgiving if the IBindingList is not implemented properly.
No, IMO, the workaround could not cause the problem; to the contrary, it helped to identify the issue.
Possibly, it matters that the port from 1.1 to 2.0 was “mechanical” (with the conversion wizard): we did not try to use the new ObjectDataSource.
Sorry guys for this late response...
ajj3085, it's been as easy as overriding AddNewCore on my list object.
Thanks to the rest of responses though they were on a different direction.
Copyright (c) Marimer LLC