I have connected a BindingSource to an entity collection at runtime and it seems to work fine except that the AllowRemove property of the BindingSource is false which means the the Delete button in the BindingNavigator is disabled. Why is this?

However if I connect the BindingSource to an entity the property, and hence the button, is enabled.

Of course I can delete(Remove) in code but I would like to be able to use that button rather than create a new one.

Im using: VS 2005RC Winforms, LLBLGen v1.0.2005.1 - SelfServicing

set the AllowRemove property of the collection to true, it's false by default.

Otis wrote:

set the AllowRemove property of the collection to true, it's false by default.

Opps shoulda searched forums for "AllowRemove"

FTR. I had tried setting the AllowRemove property of the BindingSource to true but it was Readonly but casting it to an EntityCollectionBase fixed that. e.g. (userCollectionBindingSource.DataSource as EntityCollectionBase).AllowRemove = true;

As an aside and nothing to do with LLBLGen Pro but the Delete button only delete's the current item in the collection(as you would expect) but if your got a dataGridView with the same datasource and you select multiple rows and press delete it removes all the selected rows - Allowing both could be confusing to a user.

Also, in the documentation under Design time support in VS.NET 2005 is says "You should use the BindingSource used on your form to only setup the grid, and you should select an entity class, not a collection class." Since the BindingSource.Datasource is been set at runtime surely it doesn't matter which is dropped on the form? I've not noticed any difference.

TomDog wrote:

Otis wrote:

set the AllowRemove property of the collection to true, it's false by default.

Opps shoulda searched forums for "AllowRemove"

FTR. I had tried setting the AllowRemove property of the BindingSource to true but it was Readonly but casting it to an EntityCollectionBase fixed that. e.g. (userCollectionBindingSource.DataSource as EntityCollectionBase).AllowRemove = true;

((EntityCollectionBase)userCollectionBindingSource.DataSource).AllowRemove = true; is more efficient

As an aside and nothing to do with LLBLGen Pro but the Delete button only delete's the current item in the collection(as you would expect) but if your got a dataGridView with the same datasource and you select multiple rows and press delete it removes all the selected rows - Allowing both could be confusing to a user.

Odd. Could be it's something new in .NET 2.0, something like 'multiselect' or something, which isn't supported in the current llblgen pro code yet. I've to look into that in the near future.

Also, in the documentation under Design time support in VS.NET 2005 is says "You should use the BindingSource used on your form to only setup the grid, and you should select an entity class, not a collection class." Since the BindingSource.Datasource is been set at runtime surely it doesn't matter which is dropped on the form? I've not noticed any difference.

Then it doesn't matter. That disclaimer is meant to avoid having a binding source with 'CustomerEntity' for example bound to a grid, because teh bindingsource creates a List<CustomerEntity> in that case, not an entitycollection.

In my experience it often works better to use:

((EntityCollectionBase)userCollectionBindingSource.List).AllowRemove = true;

Which exposes the binding source's underlying list rather than DataSource. The difference comes when you have nested binding sources in nested master detail relationships. Then the datasource may be another BindingSource--but the list will be the underlying LLBLGen Pro collection.

Although in this case, you'll need to reset the property value when the selected item in the master is changed.