Ok. I know this is slightly off topic for this forum, but I also know that there are quite a few developers on here that use both Infragistics and CSLA. Here is my problem:
I'm using the following code to save my business object (BLB):
BindingSource.RaiseListChangedEvents = false;
BindingSource.EndEdit();
UltraGrid.UpdateData();
//Some custom business object save code here
BindingSource.RaiseListChangedEvents = true;
BindingSource.ResetBindings(false);
As far as I know, this is code is pretty common for saving business objects. I have setup my grid/form so that the business object will be saved each time that the user changes rows in the grid. My problem is with the BindingSource.ResetBindings(false) line. This causes the grid to "resort" the data in the grid, which is really annoying to users as the row they just modified gets moved by the sort. What I'd really like to do is sort the data when the form opens, and then not again unless I specify in code, or the user clicks on the column headers. Anybody got any ideas as to how to fix this issue?
Thanks,Yeah. It's an ERLB. Basically I have to call the ResetBindings() because, as you know, CSLA returns a clone when you save an object. When I put that code in, it causes the grid to perform the sort again, which could cause the record that the user was editing to move around in the grid.
Dustin
Thanks for the feedback. Actually I'm already using a Guid for both the business object's GetIdValue and the primary key in the database. If only there was some way to disable the automatic sorting so that it didnt' try to sort when the ResetBindings() ran.
Dustin
dshafer:
Yeah. It's an ERLB. Basically I have to call the ResetBindings() because, as you know, CSLA returns a clone when you save an object. When I put that code in, it causes the grid to perform the sort again, which could cause the record that the user was editing to move around in the grid.
Dustin
Wait. An ERLB does replace the individual child that was saved, but the list object itself is never cloned and is not a mobile object.
If you have an editable root list (BusinessListBase), then you'd get back a new list object when calling Save(), and you'd need to rebind.
Rocky,
You are correct. Sorry for the confusion, I misinterpreted the ERLB abbreviation. I'm uing an editable root list (BusinessListBase) and therefore it is giving me a new object back on the save. A co-worker of mine found the ResetCurrentItem method on the binding source that seems to do the trick. Have any of you ever used this command instead of the binding source's ResetBindings method?
Dustin
I have not used either.
When you get back a whole new root object, you need to replace
the bindingsource.DataSource with the new object. I don’t believe
ResetX() will update the DataSource at all. Instead, you must unbind the old
value and then bind to the new value.
The version 3.0.2 code is the only known correct code in this
regard (in PTWin – www.lhotka.net/cslanet/download.aspx).
Rocky
From: dshafer
[mailto:cslanet@lhotka.net]
Sent: Friday, September 07, 2007 7:55 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] OT: Infragistics grid insists on resorting grid
after every save
Rocky,
You are correct. Sorry for the confusion, I misinterpreted the ERLB
abbreviation. I'm uing an editable root list (BusinessListBase) and
therefore it is giving me a new object back on the save. A co-worker
of mine found the ResetCurrentItem method on the binding source that seems
to do the trick. Have any of you ever used this command instead of the
binding source's ResetBindings method?
Dustin
Rocky,
We are actually already doing the bsToSave.DataSource = _newListAfterSave..... We were trying to use the bsToSave.ResetCurrentItem method to get the Infragistics grid to "update it's link" with the binding source, without actually resorting. So far it looks successful, but I've never used this command before so I was wondering if anyone else had. We'll keep an eye out for any odd behavior and test like crazy to make sure it's acting correctly. Thanks for the feedback.
Dustin
Copyright (c) Marimer LLC