We're building an application around locally referenced objects as data stores.  Basically, we manage object propagation through WCF callbacks, but keep a locally referenced singleton instance of each object.  We're looking for a good way to manage the edits on these objects-- We do not want to directly edit them through the grid, so interrupting the editing process seemed prudent.

 My only issue is this:  While we can cancel the edit, we can't actually get information on the proposed edit from a "whole object" sense (think DataRow.EditedDataContext ), and would have to manually index through the cells.  This is certainly not ideal from either a performance aspect or a reusability aspect (instead of one generic extension of DataGridControl we would have to manually implement this throughout our app).  Do you have any suggestions that could make this more manageable, granting that we both do not want to directly edit the objects and wish to maintain list reference viability?  Real time updates are a must, and this is managed through the locally cached list.

I am not certain that I understand what you are trying to accomplish. Would it be possible for you to provide more information on your scenario?

---

Technical Writer/Technical Support Team Manager - Xceed Software

In three words I can sum up everything I've learned about life: it goes on.

Basically, we have a list of objects we don't want to directly commit edits to.  Basically, we would like to "Capture" the edited object without actually allowing the editing process to complete, and post that edit to a server.  Looking at the routed events for editing, it seems like the actual information about the proposed edit isn't transferred in the event arguments (They're just Cancel*routedeventargs?), but my goal is to find a good way to capture these edits in a generic sense-- I don't want to have the same interruption code in every view because the only method we have available to us to capture the edits is through a direct cell lookup.

If I understand correctly, you want to take possession of the items to commit and not have the grid handle it. In the case, you could try handling the EndingEdit event defined by the Row class to access the .Content of all the cells and do what you need to there.

This assumes that you have set the UpdateSourceTrigger property on the grid to RowEndingEdit.

Hope this helps! 

---

Technical Writer/Technical Support Team Manager - Xceed Software

In three words I can sum up everything I've learned about life: it goes on.

Ah, yes, we certainly have gotten there already.  My one issue with that approach is that there is much cell-specific, replicated code in each datagridcontrol we're going to implement-- My ideal would be something generic that we could put in a single extension to the DataGridControl.  Do you have any suggestions?  My original hope is that there would be a floating "Proposed object" that contained the edits that I would be able to access, but it does seem like accessing them through the cell is the only current supported approach.

 

 

When you state "My one issue with that approach is that there is much cell-specific, replicated code in each datagridcontrol we're going to implement" what exactly do you mean? Also, you mention "single extension". If you are using "extension" to refer to deriving, then the EndingEdit is a routed event, which means that you can handle it on the grid or on your grid-derived class. I am afraid that I may not understand what the problem is nor what you are looking to accomplish...

---

Technical Writer/Technical Support Team Manager - Xceed Software

In three words I can sum up everything I've learned about life: it goes on.

Ah, sorry for not being more clear.

 

We're going to have this situation (the desire to interrupt the editing process and retrieve potential edits) in many grids across our suite.  So, my natural inclination is to figure out an inexpensive (cpu cost) way to consolidate this code into a single derived class (From DataGridControl) which would then raise an event with the "Proposed" object in its entirety to an outside consumer.

 

Basically, I think I've figured out the datagridcontrol in its current incarnation doesn't offer this up, with the alternative being mining the datacells themselves for the proposed edits.  My preference is to avoid doing that, as it would be repeated everywhere in our application, and provide multiple potential points of translation failure.

 

A comparison of the workflows:

Xceed in its current incarnation:

1. Interrupt EndingEdit, which tells me where the edit is ending from.
   
2. Mine all data cells in a given row for potential edits.
3. Take this object, pass it to my outside persistence service.

Desired behavior :

1.  interrupt EndingEdit, which tells me exactly what the proposed edited object is
2. Raise an event which passes the proposed edit object in its event args
3. Pass this object to the service

When mining that DataCells, have you considered checking their IsDirty property? That way, you would only mine those that have been edited. If you prefer to raise an event, you could do so in the EndingEdit event if you find that cells have been edited. 

I am not certain that I can offer a solution that would allow you to do exactly what you are describing...

---

Technical Writer/Technical Support Team Manager - Xceed Software

In three words I can sum up everything I've learned about life: it goes on.

The problem isn't so much that I can't do what I want to, it's that there's not an elegant solution to it (i.e. I can't put this in an extended DataGridControl to handle multiple different object types without using something like reflection and doing a reverse lookup of column / field names). 

 I was mainly interested to know if there was something I was missing, but it seems like you're following down the same road I initially tried to steer clear from.

 

Thanks for your help,

Brandyn.