I have the same issue with nested properties.

<telerik:DataFormRadNumericEditor
PropertyName="Current.Amount"
HeaderText="Amount:"
Minimum="0"/>

changing value on form gives me error:



When I'm trying this

<telerik:DataFormRadNumericEditor
PropertyName="{Binding Current.Amount}"
HeaderText="Amount:"
Minimum="0"/>

i have got this error:



The same error occurred when i'm trying other ways of binding with BindingContext changed

<telerik:RadDataForm
x:Name="dataForm"
BindingContext="{Binding Current}"
x:DataType="model:ObservableInvEntry"
AutoGenerateItems="False">

<telerik:DataFormGroup
HeaderDisplayOptions="Text"
HeaderText="Basic information"
GroupName="BasicInformation">

...

<telerik:DataFormRadNumericEditor
PropertyName="{Binding Amount}"
HeaderText="Amount:"
Minimum="0"/>

</telerik:DataFormGroup>
...
</telerik:RadDataForm>

I'm using CommunityToolkit to implement observable objects so I have tried to do this according to your example:
https://docs.telerik.com/devtools/maui/controls/dataform/data-binding
and nothig has changed.

<telerik:RadDataForm
x:Name="dataForm"
BindingContext="{Binding Current}"
x:DataType="model:ObservableInvEntry2"
AutoGenerateItems="False">

<telerik:DataFormGroup
HeaderDisplayOptions="Text"
HeaderText="Basic information"
GroupName="BasicInformation">

<telerik:DataFormRadNumericEditor
PropertyName="{Binding Amount}"
HeaderText="Amount:"
Minimum="0"/>

</telerik:DataFormGroup>
...
</telerik:RadDataForm>

But I figure out that this approach works (also with CommunityToolkit ObservableObject).

<telerik:RadDataForm
x:Name="dataForm"
BindingContext="{Binding Current}"
AutoGenerateItems="False">

<telerik:DataFormGroup
HeaderDisplayOptions="Text"
HeaderText="Dane podstawowe"
GroupName="BasicInformation">

...
<telerik:DataFormRadNumericEditor
PropertyName="Amount"
HeaderText="Amount:"
Minimum="0"/>
</telerik:DataFormGroup>
...
</telerik:RadDataForm>

I don't know what would happen if there were more nested levels. Probably the BindingContext needs to be set to the lowest where the properties are located. In a more complex scenario, each DataForm control wrapper can have its own BindinContext to achieve the goal. In the end, validation may not work at all anyway.

I'm a beginner so I also do not know why sometimes i should do binding like this  "{Binding ...}" an sometimes like normal string "...". For me it's better when intellisense shows me if properties I use exists or not during xaml designer. Using strings is not a good idea for me.
I agree with Craig that It would be much simpler if we could use nested properties directly PropertyName="{Binding Current.Amount}" eventually PropertyName="Current.Amount" without changing BindingContext.

I thought that this is a problem with setters but may be this is a problem with validation only as Craig has mentioned.

Regards

Michael

PS. Sorry. I did not know how to put images into post directly and mark some blocks as "code". It seems like here it is not possible.

I have found exactly as Craig has found.  A natvie MAUI Entry control can bind to Authors.Name for both display and data collection.  The same should apply to the Rad Data Form Entry control.  For me I cannot use the Rad Data Form and all the other features it provides until I can collect data through it.

If you are using Entity Framework Core (EF Core) then you are using C# classes that model the Entities.

In EF Core Code First you define what the database entity relationships are by defining each entity.  If a given entity has a primary/foreign key relationship to another entity like Author and Book where there are multiple Books for a given Author, then the Author entity class would have the properties of Author but then there would be a property inside of Author like: public virtual Book Books {get; set;}. - And here you have a nested object and with EF Core you will have nested objects ALL over the place in the entity classes.

It is a massive timesaver if you can have the same Entity class be used for the Data as well as for the ViewModel. Instead of having a parallel universe copy of the Author class for instance that has the properties of Book object flattened out into it and having to have code to map/copy from the Author class to the lets say AuthorUI class that has the properties of Book flattened out into it; instead you can use the same Author class to display and edit. And realistically you may have half a dozen objects that are nested and you would have EXTREMELY non-trivial mapping code to flatten all of that. Not to mention a performance hit as well.

Otherwise, you have to have a separate AuthorUI class that has to stay in sync (every single time you modify Author, you have to know to update AuthorUI (you have to put a NOTE in the Author class that says "Please go update AuthorUI to keep it in sync". That introduces bugs and hassles. Next you have to write the from and to mapper code AND update it every time Author changes to keep the mapper code in sync. Now imagine you have to do this for many of the Entity classes because the majority will have nested objects because that is the way you work with EF Core. 

EF Core is a massive timesaver and so it is a reality that MANY people will be using it and will have nested properties.

The DataForm control is INCREDIBLY powerful and a massive timesaver. In readonly mode for a control that is mapping a nested property DataFrom actually renders the nested property correctly. E.G. the PropertyName field would be like: "Author.BookName" -- This works beautifully.

The ONLY gotcha happens when the control is not read-only and the user tries to edit the content and then a validation error occurs that says the property (the nested property) is not found. Oddly, the control is smart enough to be able to find/display "Author.BookName" with no problem but the validation is not smart enough to see that "Author.BookName" is valid. -- It naively seems trivial to update the validation logic so it sees the property is valid.

Imagine if the validation logic could be tweaked in a couple of hours or less and then you would be able to say: "DataForm now supports nested properties!!!"

The pain points for anyone using EF Core and nested objects all over the place (or anyone else for that matter that has nested objects), the pain points are pretty extreme. -- Balancing that with hopefully an extremely simple fix to the validation logic (since the rendering already finds the nested properties just fine), that would complete the functionality.

I can see having about 4-5 entities rendered in a set of groupings in a DataForm where you just pull directly from objects of the Entity type like Author vs AuthorUI and you could display all that in minutes. If you can't do nested properties then that could end up 10X the code and take you all day long to do it and then introduce MAJOR maintenance headaches/bugs!!

 

The beauty of buying Telerik controls is that you can do very powerful things with minimal effort and have it look really professional as well.

This is a MAJOR MISS I feel if DataForm does not support nested properties! It seems it would be minimal effort that would yield HUGE time savings.

 

Thanks!

Craig