Adding Rows to Child Grid

[Theo Danzfuss]

Hi,

Im getting real strange behaviour - hope u can help.

I have a Parent-Child relationship set up in my Grouping control. When I add a new child Row through the Grid UI everything works fine.

BUT when I manually Add a Datarow through code I get a NullReferenceException at Syncfusion.Grouping.Table.bindingList_ListChanged(See Full dump below...)
Im using my own collection that implements both "IBindingList" and "ITypedList". Maybe the Error lies somewhere in my implementation of these Interfaces, but I only get this behaviour when my List is bound to a Group control AND only when I add a row to the view of a child grid. Can you please give me an overview of what happens in the "bindingList_ListChanged" event when a datarow is added to my collection and what could possibly cause a NullReference Exception.

Regards,
TD

EXCEPTION:
System.NullReferenceException: Object reference not set to an instance of an object.
at Syncfusion.Grouping.Table.bindingList_ListChanged(Object sender, ListChangedEventArgs e)
at Syncfusion.Windows.Forms.Grid.Grouping.GridTableBase.bindingList_ListChanged(Object sender, ListChangedEventArgs e)
at System.ComponentModel.ListChangedEventHandler.Invoke(Object sender, ListChangedEventArgs e)
at ELogics.Esi.Client.View.ClientView.OnListChanged(ListChangedEventArgs ev) in c:\projects\elogics\vs2003\esi\2\esi.client\view\clientview.cs:line 1640
at ELogics.Esi.Client.View.ClientView.Add(Object value) in c:\projects\elogics\vs2003\esi\2\esi.client\view\clientview.cs:line 1767

[Administrator]

If you have our source code, then getting a debug build of the libraries would allow you to drill down in our source and see exactly what line/object in that method is triggerring this exception. That would be the quickest way to see what is causing this. If you can upload a sample project showing the problem, we can debug it here.

Short of that, the method itself is roughly 1000 lines of code, so I am not sure where to start suggesting what you should look at. You are adding the item to the list before you raise the ItemAdded ListChanged event, correct?

[Theo Danzfuss]

Ok, After many hours of struggling I finally managed to Debug into your code. And The exception occurs at the following location:

Syncfusion.Grouping.Base.Runtime.Table.cs ln 3889

The problem is that the oldSortKeys Array is Null. I added the following lines:

if ( oldSortKeys == null )
break;

With this line in the code I dont get the Exception and The Grid seems to work correctly, BUT I cant use it like this - I must use your preCompiled Assemblies. Could you please guide me to Why the "oldSortKeys" Array can be empty - and what I can look at.

Regards.
TD

[Administrator]

Theo,

which version are you using? Is it possible to try with the 3.3 version.

It clearly sounds as if something goes wrong here but I can''t tell what just from glancing through our code why this happens.

If you have a small sample project that you can upload I''ll debug into it.

Normally the SortKeys are null if either record.UpdateSortInfo (an internal method) was not called or if neither SortedColumns nor GroupedColumns were specified.

You could also manually set record.SortKeys = new object[0]; in case there is a event raised before that line 3389 you mentioned. You could then handle that event in your code and fix that record. One event that could be used is SourceListRecordChanging. It gets passed the record.

Stefan

[Theo Danzfuss]

I tried to set the e.Record.SortKeys property - but it is ReadOnly. Instead I now set the TableDirty property of the Table to true, but this causes other code to freak out... Is there any other way to ensure that the SortKeys is not null?

TD

[Administrator]

Theo,

You are right. It is read-only. You could instead use reflection and access the private sortKeys field in record.

FieldInfo fInfo = record.GetType().GetField("sortKeys", BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.GetField);
if(fInfo != null)
{
fInfo.SetValue(record, new object[0]);
}

Stefan

>I tried to set the e.Record.SortKeys property - but it is ReadOnly. Instead I now set the TableDirty property of the Table to true, but this causes other code to freak out... Is there any other way to ensure that the SortKeys is not null?
>
>TD

[Theo Danzfuss]

Thanx Stefan that will work for now - but it feels SOO wrong!

I still believe that it has something to do with my implementation of IBindingList.
I noticed the bug only occurs Iff I raise the ListChanged event in both the AddNew and the Add methods (As prescribed by the MSDN). If I dont raise the ListChanged event in the AddNew Method then I dont get the error?

When calling the AddNew method I do the following:
- create a new DataRow,
- create a new ID,
- allocate an index in the collection
- finally add it to a temp list
- and then raise the OnListchanged with the new Index

When calling the Add method I add the datarow to the underlying DataTable, remove it from the temp list and once again raise the OnListChange event.

This coincides with my understanding of the Add and AddNew Methods?

As already said the workaround will work for now, but I would like to find and eliminate the cause of the bug. Can you think of a reason why raising the OnListChange event twice might cause the Grid to throw the error?

Regards,
TD

[Administrator]

Hi Theo,

you still haven''t told me if you use the latest version ...

But yes - the engine can handle both cases. You can either just add the event once after the row was added or you can raise it twice both in AddNew and once you added it.

That way the engine can handle both implementations.

When AddNew is called it should give a .NewIndex. When then the record is added to the list you need to set again exactly the same .NewIndex. The grid checks whether the ItemAdded was raised for the same .NewIndex and will then handle the second AddNew call differently (it will be simply handled as an ItemChanged in that case).

So my guess is now that you maybe don''t set the correct .NewIndex and that it differs between the two calls.

Stefan

>Thanx Stefan that will work for now - but it feels SOO wrong!
>
>I still believe that it has something to do with my implementation of IBindingList.
>I noticed the bug only occurs Iff I raise the ListChanged event in both the AddNew and the Add methods (As prescribed by the MSDN). If I dont raise the ListChanged event in the AddNew Method then I dont get the error?
>
>When calling the AddNew method I do the following:
> - create a new DataRow,
> - create a new ID,
> - allocate an index in the collection
> - finally add it to a temp list
> - and then raise the OnListchanged with the new Index
>
>When calling the Add method I add the datarow to the underlying DataTable, remove it from the temp list and once again raise the OnListChange event.
>
>This coincides with my understanding of the Add and AddNew Methods?
>
>As already said the workaround will work for now, but I would like to find and eliminate the cause of the bug. Can you think of a reason why raising the OnListChange event twice might cause the Grid to throw the error?
>
>Regards,
>TD

[Theo Danzfuss]

No Im not using the latest version - We cant switch versions now.

As I Stepped through the bindingList_ListChanged code I noticed a statement that checked whether the object being added is a DataRow. If it is a DataRow then it does a dataRow.Table.Add(newRow), Else the Add is called on the IBindingList collection.

This causes problems because my IBindingList is nothing more than a fancy collection of DataRows !BUT! it doesn''t listen to the underlying DataTable s RowAdded events - thus if a row is added directly to the underlying DataRow.Table.Rows collection my IBindingList will not call Add and the ListChanged Event will not be raised for the second time, casuing all sorts of strange problems.

Ideally I would have liked it if the IBingingList.Add is always called. But Im sure this causes some other problems.

Regards,
TD