This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
I have a winforms scenario I need help with please. 1. Open UOW and get a list of products then close UOW 2. Bind products to a BindingSource and that binding source is bound to a datagridview 3. The user deletes a product in the datagridview 4. This calls the UOW.remove however it's been disposed in 1. I understand why this is happening, but I wish to handle the userdeletedrow event and add this deleted product to another list of deletedproducts. The reason for this is so I can do the following. 1. User clicks Save, I open a new UOW, UOW.Remove each item in the deletedproducts list and finally UOW.SaveChanges. 2. Or User clicks cancel and reverts back without deleting the products by reloading the product list. I can just ignore the UOW disposed error, however there must be a better way of achieving my end goal. Thanks |
|
|
Are you loading that list of products at the top level via a Find or a LINQ query, or are you loading it through an association? Deleting out of a top-level result set should not remove the entity from the UOW. If you are seeing this then could you provide us with a simple repro so we can check it out? Thanks! Deleting out of an association collection (an EntityCollection) will cause the removal (and in your case the exception), because EntityCollection detects adds and removals and performs the UOW bookkeeping. One way around this is to copy the contents into a plain old List or BindingList, e.g. grid.DataSource = new List<Product>(order.Products); (or bindingSource.DataSource = ...). The data grid will then remove the entity from this list, not from the association, and because this list is a dumb list this will not cause a removal from the UOW. |
|
|
Hi Ivan, Yes I am loading it through an association. If I copy the contents into a plain old List or BindingList then what is the best way of getting the datagridview edits back into the EntityCollection for updating? Or is using an entitycollection for this purpose flawed in the first place? I guess I am trying to find a way to do this simply. e.g. Loading my orders and it's products through eager loading and then updating the products and then saving the changes by attaching the orders (and therefore the products) to a new UOW and saving. The gotcha is that I may not want to delete a product and cancel the changes. Maybe I should load the products using a Find and then save them separately. Any suggestions. Also I am having a problem with a combobox column in a datagridview. When the datagridview creates a new line, the underlying entity ID is set to 0. My combobox column is bound to a list that doesn't have a 0 id in it and I get a {"DataGridViewComboBoxCell value is not valid."} exception. I guess the datagridview expects a system.dbnull.value to function correctly. Other people must have this problem and a way around it. BTW a Winforms samples would be great. Specifically using datagridview to update data, combobox colums in the datagridview and validation. |
|
|
You don't want to get the edits back into the original EntityCollection, because that is associated with the old, disposed, UOW. Instead, you would have to create a new UOW for the save, and can then either (a) reload the edited entities by ID in the new UOW, and copy the edits across or (b) attach the edited items to the new UOW using IUnitOfWork.Attach(). The second option is obviously the easier one (it also works better with optimistic concurrency checking). The other approach of course is to hold the UOW open for the duration of the edit cycle, i.e. until the user chooses either Save or Cancel. This is definitely the simplest option provided that you do not need to see other users' changes while editing is in progress (and that the user is not going to spend a very long time on a single edit cycle). This will still meet your requirement to be able to cancel, because nothing gets committed until you call IUnitOfWork.SaveChanges (though you will not be able to back out the deletes while still keeping the edits, if that is what you are asking for). I'll have to investigate the combo box issue, but it might be more convenient for your users for the combo box to display a list of entities rather than a list of IDs: we generally try to avoid showing IDs because they're pretty opaque and you can't control them. (If you want to show a short code for rapid selection then we'd suggest a short code property rather than the ID itself.) In these cases your combo box data source would presumably include a null value (possibly with a friendlier display name such as "Select...") which might get around the problem. But obviously I don't know your app so this may be a dumb suggestion! We are keen to produce a Windows Forms sample and we definitely plan to do so in the run-up to 3.0 but we are a bit backlogged at the moment so I'm afraid this probably won't happen in the next few days. Thanks for the feedback and suggestions though! |
|