User login |
Adding EntitiesOnce a BindingSource is hooked to a LinQ EF query, editing/deletion become trivial. But how about adding new objects? My first attempt, it turns out, was just backwards: I added a new object to the EntitySet and then added that new object to the BindingSource. While this worked, it causes havoc in the ObjectStateManager - key inconsistencies, etc. Turns out the pattern is this: Add a new object via the BindingSource: User u = (User)UserVarBindingSource.AddNew(); That's it. The new object is created and added to the underlying list (in this case the EntitySet) and the BindingSource will position itself (and all bound Controls) to the new records. But that's not quite the end of the story - the new object probably requires some type of initialization and if that's explicitly done in a default constructor then it needs to be done as a result of the add operation. We make use of the BindingSource's AddingNew event to set a flag indicating that a new object is added:
private void UerBindingSource_AddingNew( object sender, AddingNewEventArgs e )
{
m_adding = true;
}
Then utilizing the CurrentChanged event (after the object is added the BindingSource sets it as the current object, triggering this event) the new object is initialized:
private void UserBindingSource_CurrentChanged( object sender, EventArgs e )
{
// adding new object flag set in AddingNew event handler
if ( ! m_adding )
return;
// reset the flag so we don't modify every object viewed
m_adding = false;
//
// fetch the new object and dress it up
Model.User usr = (Model.User)UserBindingSource.Current;
sv.name = "NoName";
....
// The object is stil in the 'edit' state which means the changes will not
// be propogated to the underlying layer - end the edit so the object is "live".
sysVarBindingSource.EndEdit();
}
The call to EndEdit is important - either at this point or prior to saving the data: if EndEdit isn't called, the BindingSource does not propogate changes to the underlying data store (hmmmmmm.... undo anyone?).
|