Thank you Vladimir.

Your understanding is correct. It would be great if it supported non-default constructors, but it would be a huge benefit even if it required a default constructor (and set properties as usual).

I'm sure your designers can come up with a great layout, but I'd be happy to sketch it if there's still any uncertainty.

No, that's not what I'm looking for. I feel like for some reason like I'm not being able to convey to you what seems like a simple ask.

Here's one example...

Each payment from the customer contains any number of detail lines - usually several hundred. These payment remittance details are based on how their system works, not ours. They aren't tied to invoices in the classical sense, and that makes it difficult and time consuming for accounting. My application matches them up and does all the work, but in some cases there are insufficient details. The user needs to match those remittance detail exceptions to invoices.

I have a class, it represents an invoice match and it contains a reference to an invoice and the amount to be applied as payment against the invoice. Using the RadGridView I want the user to be able to choose an invoice and an amount (it'll default to either the amount unmatched against the remittance or the full amount of the invoice whichever is less). However, after that match is made the user can only (1) change the amount or (2) delete the match entirely.

Right now, the RadGridView doesn't support #1 without allowing you to change the invoice too. It's worth noting that a NewRowTemplate (what I'm asking for), or even the equivalent at the cell level (a companion to the CellEditTemplate) would also allow me to pre-filter the contents of the ICollectionView backing the list of invoices that are displayed. This allows me to greatly narrow down the list of invoices based on things like item, shipment, document, and amount without affecting the display of anything that has already been matched.

I want to stress that I don't need or want a solution using an external component. I've already developed that for my example due to the RadGridView being deficient in this area. This would still be very useful for me, because this isn't the first time that the need for the feature has come up for me -- I have a few ideas of where I'd use it in an upcoming project.

Thank you for following-up. No, that won't solve the use case which is for the user to be able to provide the information with the data grid for the purpose of constructing the instance. Using that event presumes that the needed state is already known, or will be gathered in another way (which I'm forced to do now anyway).

Even if the grid couldn't technically handle the non-default constructor, the value is there in having a different template between adding and editing and keeping things controlled by the datagrid. I could see several instances where having this feature would be beneficial to me. I believe Infragistics had something like this (could've been their Windows Forms controls - it's been years since I used them).