Yes, I allow filtering, but I still don't understand why this object needed. Also, I use filtering as Filter menu and I don't see the similar approach with AddNewRow functionality. What does this object do in the internal logic of the XamGrid?

Hello Vasily,

Internal to the XamGrid, if filtering or an AddNewRow is enabled, we use reflection to attempt to create an empty object of the type that corresponds to a particular ColumnLayout in the grid. For filtering, this is used as a sort of placeholder to filter against. For the AddNewRow, this is used as a placeholder "template" for an underlying data item to correspond to the new records that will be added to the grid, and as such, the underlying collection. It appears to me that much of this is likely done for performance reasons, as we wouldn't want to get the underlying type of the data items to the rows for each row filtered or added each time we go to do this operation and so the placeholder is used to prevent this unnecessary overhead.

If there is no default, parameter-less constructor for the elements to be created via reflection, we require that you create one and return it in the DataObjectRequested event. We cannot assume that we need to pass N number of parameters to the element we create, as this number could be any number of parameters. As such, I would recommend that you either return an "empty" object from the DataObjectRequested event as shown in the forum thread linked above, or add an empty, parameter-less constructor to your underlying data item, if possible.

Please let me know if you have any other questions or concerns on this matter.

Sincerely,
Andrew
Associate Developer

So does this mean that if you intend on using filtering in your xamGrid that the view model for the object must always have default values when called with the parameter less constructor?

For example, you couldn't do something like this, as doing so could result in null reference exception if the Infragistics code were to create an instance of the class calling the parameter less constructor and then tried to access it's property:

// Parameterless constructor to satisfy this requirement.

class SomeClass()

{

}

// Actual constructor that gets called throughout the code.

class SomeClass(object someObject)

{

  _someObject = someObject;

}

// Property1, which will throw a null reference exception if accessed when the object is constructed from the parameter less constructor

bool Property1

{

  get

  {

   return _someObject.BoolProperty;

  }

}

Are you able to just create a new instance of someObject in the parameterless constructor?  That is probably the best way to avoid the issue.  Note I am not sure if we actually access the property for the filter row.

Alternatively, is there a reason that you don't just expose a property for someObject instead of its child properties so that they can be accessed that way?

In this scenario it isn't that the view model object can't return null, it is that its properties aren't expected to throw a NullReferenceException.  You could also check if the someObject is null and return a null value or equivalent value from your property if the object isn't set.

I'll look into it. The only reason I ask is that we are occasionally seeing a null ref exception when filtering on one of our xamGrids. The view model is implemented in a way similar to how I've shown above. The stack trace points us to a get_Property method returning null and the only way that's possible is if the object was constructed using the parameterless constructor. Just wanted to verify that it's even possible and figure out if we need to change our implementations if that's a possibility. I wasn't able to find any sort of documentation that said that the view model object should always have default non-Null values on it's properties.