CSLA v3.6 + DataGrid Help Desperatly Needed

CSLA v3.6 + DataGrid Help Desperatly Needed

Old forum URL: forums.lhotka.net/forums/t/6131.aspx


AndrewBurns posted on Monday, January 12, 2009

Hello all,

I have been searching the forums for the past two hours trying to fix my problem.  I got it half fixed, but that extra mile is killing me and so I am reaching out in need.

I have an Invoice with line items.  One binding source and a grid (DevExpress XtraGrid) for the line items.  The grid is bound to DataSource=BindinSource DataMember="LineItems".

The original problem I had was when tabbing into the grid (Qty column first) it would ALWAYS eat the first key of every row.  Thanks to the forums I got that fixed (Changing child properties after it was added to the collection in AddNewCore) and the first line enters as expected now.

The problem is on addition lines.  As soon as I tab out of the first column (Qty) it will reposition my selection to the first row; however the row I just added is in the correct place (bottom of the list). But because the selection has changed I can not continue to enter data.

I have been pulling my hair out changing settings and code to no avail, can someone give me some insight?

Thank you so much in advance!
Andrew

AndrewBurns replied on Thursday, January 15, 2009

Polite bump.

I have contacted Developer Express and they basically said unless you can reproduce the issue in this sample solution we have provided then we don't care.  Has no one ran across this issue?

Thank you,
Andrew

tetranz replied on Thursday, January 15, 2009

I don't have a solution but have you tried reproducing the problem with a bare bones demo app, preferably using regular .NET objects rather than CSLA?  If you could do that and demonstrate that the standard MS DataGridView works and their grid doesn't then that would be harder for them to ignore.

It sounds like something to do with bubbling up ListChanged events from the collection to the root. That causes problems. See http://forums.lhotka.net/forums/thread/24802.aspx When you tab out of Qty, if you've changed the value then that causes PropertyChanged on the child, ListChanged on the collection and then, if you're bubbling events and fire a PropertyChanged on the root, the way Windows databinding works is that it refreshes every property on the root including the collections. That means your grid then gets a ListChanged, reset event. Maybe that's what's making the grid go back to the first row.

Are you bubbling up ListChanged events from the line items to cause a ProperlyChanged event in the invoice?  If you are then you probably shouldn't do that.  I guess it's hard to avoid if you want changes in the line items to update a total or something in the invoice.

Of course, all that might be completely irrelevent.

Ross

AndrewBurns replied on Thursday, January 15, 2009

tetranz:

Are you bubbling up ListChanged events from the line items to cause a ProperlyChanged event in the invoice?  If you are then you probably shouldn't do that.  I guess it's hard to avoid if you want changes in the line items to update a total or something in the invoice.



Ross,

Thank you SOOO much, that is EXACTLY what it was.  I feel slightly stupid now as I read over and over in the forums about WinForms databinding acting stupid be for some stupid 'forest for the trees' reason I did not think it applied to me.  I disabled all the code I had to update totals and such on the main invoice and it worked as expected!  Now that I know what the cause is I can get a work around in place.

Thank you again!

tetranz replied on Thursday, January 15, 2009

AndrewBurns:
Thank you SOOO much, that is EXACTLY what it was.

I'm happy to have helped Smile [:)]

It made me look at my recent code where I'm doing exactly what you're doing with an order / invoice type object and collection. ListChanged on the collection triggers a recalculate of some totals which updates properties on the root. I'm using the Janus grid and that seems to work okay. I guess it preserves the row position when it gets a ListChanged reset.

I did notice something that I'll report in another thread. A change to a child property seems to create two ListChanged events rather than one. If you're using the latest CSLA, I think where possible it's better to use ChildChanged instead of ListChanged. That only occurs once.

I wonder what happens now if you change a property on your root? Does the grid return to the top?

Ross

Copyright (c) Marimer LLC