Home Forums WPF controls Xceed DataGrid for WPF AddingNewItem should always be raised

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • User (Old forums)
    Member
    Post count: 23064
    #21956 |

    Hi guys,

    I have a custom datasource class which implements IEnumerable<T> and INotifyCollectionChanged. I’ve bound it as the ItemsSource of an XCeed data grid.

    Looking at the grid through Reflector, it seems that the DataGridControl.AddingNewDataItem event is only raised when no ItemsSource is specified. If the current ItemsSource isn’t an IBindingList, it throws an exception.

    This makes it difficult to use the grid with custom collections. The grid seems happy to rely on INotifyCollectionChanged to update the items, so the only reliance on IBindingList seems to be for the AddNew() method. For a number of reasons, I don’t wish to implement IBindingList on my custom collection. Since I’m using a data source, there seems to be no way for me to create new data items for an InsertionRow.

    My suggestions:

    1) Always raise the AddingNewDataItem event (or another event) even if there is an ItemsSource. This will allow people to bind to custom collections but to add their own code for when an item is added. If the event is handled and a new item is returned, then perhaps you wouldn’t even call AddNew() on the IBindingList – this would allow people to bind to IBindingLists and add their own code when creating custom items.

    2) I don’t believe IBindingList is supposed to be used anymore in WPF. INotifyCollectionChanged allows you to hook into events when the data source changes (and offers more functionality over IBindingList.ListChanged), and the CollectionView classes provide all the functionality needed around sorting (from memory).

    Any temporary workarounds would be great.

    Cheers,

    Paul

    Imported from legacy forums. Posted by Paul (had 5328 views)

    User (Old forums)
    Member
    Post count: 23064

    Hi Paul,

    The purpose of the AddingNewDataItem event is to allow the DataGrid itself to add a new item to the grid in unbound scenarios (i.e. when there is no ItemsSource). This is why we only raise it when there is no ItemsSource.

    In bound scenarios (when there is an ItemsSource), we cannot add new items directly to DataGrid.Items so we must always go through the source collection to add new items.

    In the current version, we require the source collection to implement IBindingList to support data insertion although we plan to extend that to IList (and possibly to ICollection) as well.

    In your case, since your source collection is “only” IEnumerable, there would be no way for us to add a new data item because IEnumerable doesn’t expose any method that allows that. To support insertion in that scenario, we’d probably need a different event that would be used to ask the user code to add a new data item to its source collection. I’ve just added a note to the feature spec to make sure that we consider this requirement.

    In the meantime, there is unfortunately no workaround… To support insertion, you must either implement IBindingList on your source collection or use the DataGrid in unbound mode, i.e. you don’t specify an ItemsSource and you manually fill the DataGridControl.Items collection, and handle the AddingNewDataItem event.

    Regarding your second point, we are not aware of any WPF-specific interface that supports adding new data items to a source collection, so we believe that IBindingList still makes sense for that purpose in the WPF world.

    Imported from legacy forums. Posted by Pascal (had 403 views)

    User (Old forums)
    Member
    Post count: 23064

    Hi Pascal, thanks for the comment.

    >> Regarding your second point, we are not aware of any WPF-specific interface that supports adding new data items to a source collection, so we believe that IBindingList still makes sense for that purpose in the WPF world.

    I agree, so the only need for IBindingList is for AddNew(). Since there are alternatives as you mentioned (IList, or an event that asks the user to do the insertion), the need for IBindingList could be a pain point. Most people in a WPF world wouldn’t be using IBindingList or BindingList<T> with their objects – they’d use an ObservableCollection<T>.

    >> To support insertion in that scenario, we’d probably need a different event that would be used to ask the user code to add a new data item to its source collection.

    I’m actually quite fond of that approach. Ideally, this would be my preferred outcome:

    Raise an event like “NewObjectNeeded”. This would be raised before the InsertionRow is created, so that the InserionRow always works against a real object. When the InsertionRow is edited and comitted, raise a “NewObjectAdded”. This would allow the user to add the item to the underlying list.

    One of my bugbears about the InsertionRow is that it doesn’t work on a “live” object. This means you can’t do any kind of validation or logic in your objects until the InsertionRow is comitted. I can’t think of a reason as to why the InsertionRow can’t work on a live object.

    Paul

    Imported from legacy forums. Posted by Paul (had 353 views)

    User (Old forums)
    Member
    Post count: 23064

    <i>the need for IBindingList could be a pain point</i>

    The day we fully support the InsertionRow (by implementing the proposed events, for example), there won’t be a <i>need</i> for IBindingList anymore. We’ll continue supporting it, of course, but it won’t be required.

    The outcome you propose is in line with our preliminary thoughts on what the design should be, so that’s a good sign! 🙂

    As for why the InsertionRow doesn’t work on a live object: it bugs us big time as well. We had to do this to work around some problems where a UI container was generated for the new data item with certain data sources and under certain circumstances, and we did not have as much control as we would have liked over that process… We are currently working on a solution to this problem and our goal is to make the InsertionRow work with a live data item.

    Thanks for your valuable feedback!

    Imported from legacy forums. Posted by Pascal (had 240 views)

    User (Old forums)
    Member
    Post count: 23064

    First off, great control 🙂

    now having said that, I also have a number of ObservableCollections that I wish to bind and enable insertion with.

    Is there any timeframe for the planned expanded support for InsertionRows to work with IList based collections? Just so I can know if its worth me making an IBindingList version of ObservableCollection or not

    Also any chance of a build in delete button column? (after all you do have insert and edit…:P)

    Thanks

    Adam

    Imported from legacy forums. Posted by Adam (had 310 views)

    User (Old forums)
    Member
    Post count: 23064

    Adam,

    I prefer not to provide a timeframe here, but what I can tell you is that we are working on this right now and have been for a couple of weeks now. So this is more than a feature sitting on a list of things to do, it is a feature being implemented as I am typing this message.

    As for the “delete button”, its omission is by design: since there is no standard way of presenting a Delete button in a data grid control, we feel like the best person to decide if/where a delete button should go is the application developer. And since it is not that hard to do, we decided that the grid should not provide it.

    But we are considering adding a DeleteCurrentRowCommand to the grid’s commands, to make it easier for you to add a button in your app that would be bound to that command.

    Imported from legacy forums. Posted by Pascal (had 565 views)

    User (Old forums)
    Member
    Post count: 23064

    Hello,

    I was just wondering how far you guys are with your goal “to make the InsertionRow work with a live data item”….Will it be in the next release scheduled for beginning of May??

    Thanks
    Arjan

    Imported from legacy forums. Posted by Arjan (had 6383 views)

Viewing 7 posts - 1 through 7 (of 7 total)
  • You must be logged in to reply to this topic.