[2005] DataBinding Issues

Let's say we have a Customer Maintenance form. This form displays information about the customer and the last order placed by the customer. You click a button to "Add" a new order and you are shown the Order Maintenance form with a few textboxes and a DataGrid control. Beside the DataGrid control, you have an "Add" button to add new line items to the order. Clicking Add takes you to the Line Item Maintenance form.

This setup sounds like a typical configuration. If everything is created using DataBound controls and the only "Save" routine is on the Customer Maintenance form, how would you handle this?

You open Customer# 111. You note that there is no Last Order information displayed and click to Add a new order. You enter a little bit of information about the order, then you click to Add a line item. Behind the scenes, you call EndCurrentEdit on the OrderHeader DataTable so that the data is persisted back into the DataSet and the new Identity is available. This new Identity is passed to the Line Item Maintenance form. Now you decide you don't want to save any of this order information and click cancel to get out of the Line Item Maintenance form and cancel to get out of the Order Maintenance form. Now, you look and the Last Order information has data in it relating to the order you just decided not to save.

The problem is that since you have already called EndCurrentEdit on the OrderHeader table and have persisted the data back to the DataSet, how do you revert back to the way it was prior to having clicked on Add?

Create a DataSet on the Customer form containing all the tables. When you open the Orders form pass the DataRow for the order and the table for the order items. When you open the Order Items form pass the DataRow for the item. Any changes you make to any data is reflected in the DataSet on the Customer form so when you close the Customer form you simply save all the data.

That is pretty much the way I have it working. I have a DataSet on the main form that contains the 3 tables. When I call the Orders form, I pass in the DataTable for Orders and the DataTable for OrderItems, etc.

The problem I have is this. When I create a new Order, I call BindingContext.Item(Orders).AddNew() in the Load event on the Orders form. Then, when I want to create a new OrderItem, I call BindingContext.Item(Orders).EndCurrentEdit() to get the correct OrdersIdentity to use in the OrderItems table. Now, I decide I don't want to keep anything and cancel out of the OrderItems form and then the Orders form. However, since I have already called EndCurrentEdit() on the Orders DataTable, it still shows the newly created row.

There must be some other way to handle the data binding that I am missing.

Any thoughts?

I came up with a work-around (or maybe this is the way to do it), but I think it is far more complex than should be necessary.

I am still stuck on this. Do I need to try to explain it better?

Thanks in advance.

The RejectChanges method of a DataRow returns it to its original state. From the help topic for DataRow.RejectChanges:

Quote:

---

When you call the RejectChanges method, the CancelEdit method is implicitly called to cancel any edits. If RowState is Deleted or Modified, the row reverts to its previous values, and RowState becomes Unchanged. If the RowState is Added, the row is removed.

---

That last sentence is what's relevant to you.

Yeah, but what if the user added a new order and then started adding another new order and cancelled the second one. Calling RejectChanges for the second order would revert everything back to the original state and the first order would be gone, too.

Or, what if the user added an order accepted everything and went back to the Customer form (nothing commited to the database yet). Then the user selected to edit the order and then cancelled the changes. Even though the user wanted to keep the original order, calling RejectChanges would clear everything out.

Quote:

---

Originally Posted by Aspnot

Yeah, but what if the user added a new order and then started adding another new order and cancelled the second one. Calling RejectChanges for the second order would revert everything back to the original state and the first order would be gone, too.

---

No it wouldn't. I said call RejectChanges on the row, not the table.