Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > LLBLGen Pro Runtime Framework> BindingSource collection deleting
 

Pages: 1
LLBLGen Pro Runtime Framework
BindingSource collection deleting
Page:1/1 

  Print all messages in this thread  
Poster Message
TomDog
User



Location:
Wellington, New Zealand
Joined on:
25-Oct-2005 22:21:17
Posted:
570 posts
# Posted on: 25-Oct-2005 23:23:15.  
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
Jeremy Thomas
VS 2017 C#, LLBLGen v5.4, Winforms, WPF and ASP.NET MVCLLBL & LinqPad
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37860 posts
# Posted on: 25-Oct-2005 23:49:00.  
set the AllowRemove property of the collection to true, it's false by default.

Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
TomDog
User



Location:
Wellington, New Zealand
Joined on:
25-Oct-2005 22:21:17
Posted:
570 posts
# Posted on: 26-Oct-2005 03:46:45.  
Otis wrote:
set the AllowRemove property of the collection to true, it's false by default.

Opps shoulda searched forums for "AllowRemove" Embarassed

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.
Jeremy Thomas
VS 2017 C#, LLBLGen v5.4, Winforms, WPF and ASP.NET MVCLLBL & LinqPad
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37860 posts
# Posted on: 26-Oct-2005 09:58:54.  
TomDog wrote:
Otis wrote:
set the AllowRemove property of the collection to true, it's false by default.

Opps shoulda searched forums for "AllowRemove" Embarassed

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 Wink

Quote:

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.

Quote:

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.


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
scotru
User



Location:
College Place, WA
Joined on:
16-Feb-2006 01:03:42
Posted:
104 posts
# Posted on: 28-May-2013 01:09:26.  
In my experience it often works better to use:

Code:
((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.

  Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.