I've sent it across. Thank you.
Yes the file has changed but I was going to address that in another thread but I'll quickly mention it here. When I had the templating issue on the dropdowns for displaying multiple columns you gave me this code:
${((data as Player).Forename)} ${((data as Player).Surname)}
This no longer works. So, I had modified the template to at least make it work and then I was going to come back to you on that issue.
Thanks.
I think we managed to reproduce the compilation error.
The workaround indeed doesn't work (and shouldn't have been required). We will try to fix that as well.
Getting this compile error today as well. Weird, the change event worked a day or so ago.
Any workarounds?
Today's release contains a fix for this issue. You need to add the Change handler again though.
Thanks! Works great!
I'm getting the same error with a change event of an inline edit grid textbox.
dotnet: obj\Debug\netcoreapp3.1\Razor\Pages\Shipment.razor.g.cs(771,280): error CS1503: Argument 2: cannot convert from 'Microsoft.AspNetCore.Components.EventCallback<int?>' to 'Microsoft.AspNetCore.Components.EventCallback'
TValue on the textbox is 'dynamic'.
<RadzenGridColumn TItem="MailBlazorC.Models.Inventory.ShipmentItemsDetail" Context="mailBlazorCModelsInventoryShipmentItemsDetail" Property="GrossWt" Title="Gross Wt">
<EditTemplate Context="mailBlazorCModelsInventoryShipmentItemsDetail">
<RadzenNumeric style="display: block; width: 100%" @bind-Value="@(((mailBlazorCModelsInventoryShipmentItemsDetail.GrossWt)))" TValue="dynamic" Name="GrossWt" Change="@((args) =>GrossWtChange(args, mailBlazorCModelsInventoryShipmentItemsDetail))">
</RadzenNumeric>
</EditTemplate>
</RadzenGridColumn>
I tried changing to 'int' but had no effect. Perhaps relating to the fact that the error is in generator (...g.cs) file?
To clarify, the text box is an Edit Template of a nested grid - so a few Edit Templates deep - if that matters(?)
Is there a fix for the above error? It's the change event of a text box contained in the edit template of a nested grid template. So a few levels nested - if that makes a difference.
TIA,
Josh
We cannot reproduce this error and don't know if there is a fix for it. This error happens when the TValue type does not match the argument of the event handler. Then the C# compiler cannot infer the right type.
Thanks @enchev. That works.
I wonder if there's an opportunity to simplify how RadZen handles page properties and infers types... What if we were required to explicitly define page properties and set their types instead of relying on the Set Property action in addition to other ways RadZen magically adds properties to pages. Would this not make things a bit easier when inferring types? Like if I had to define a collection property on the page and set the item type property to Inventory.ShipmentItemsDetail Then the grid data context would know the field property types from the model.
For example, in page built from nested grid wizard, the data property of the nested grid is set to ${rzNwModelsInventoryShipment.ShipmentItems}
I have no idea where that property came from and no way to change it's type. There isn't even a Set Property action that defines it so I assume it's generated by the execute C# action which populates the a collection property of the master.
Could we not explicitly define that collection property on the Page and then have control over it's type?
I'm sure there are levels of complexity that I don't understand - it just seems that context, page properties and inferring types has a lot of hidden magic that can be limiting and actually fowl things up too easily.
Thanks for listening.
Take care.
What if we were required to explicitly define page properties and set their types instead of relying on the Set Property action in addition to other ways RadZen magically adds properties to pages.
The Set Property action is the only way to create a property in Radzen. It is still explicit and there is no magic around it. If you don't like that you can define properties in the partial class. Radzen detects such properties.
Also changing the way properties are defined in Radzen will not solve this particular issue. It is caused by the way Blazor infers the type of a generic component. Check this thread for example: Basic property setting of TextBox Value not binding - #21 by korchev - a few very similar definitions - some of them compile without specifying the generic argument, some don't.
Microsoft tell developers to just set the generic argument if the compiler fails to infer it. Our workaround with the Attributes does exactly that. A better solution would be to set that automatically from Radzen when the user sets the Value property of a component. We will implement that at some point - already doing a similar thing for the Data property of components with items.
For example, in page built from nested grid wizard, the data property of the nested grid is set to
${rzNwModelsInventoryShipment.ShipmentItems}
This is to allow you to have nested template contexts. Consider this:
<RadzenGridColumn>
<Template Context="data">
<RadzenGrid Data="@data.Items">
<RadzenGridColumn>
<Template Context="data">
</Template>
</RadzenGrid>
</Template>
</RadzenGridColumn>
In this case the inner Context="data" won't work as "data" is defined already. Radzen generates unique name for the context. In design time you still use ${data}.
Thanks @korchev for your reply.
As I said there are complexities I likely don't understand.
For example, it's unclear when I can use ${data} and when I cannot. I gather it's available for components that contain items. So I learned something today. 
I understand the unique naming requirement on nested templates. But instead of the magic property, could you not create a page property and then the collection would exist in the Data drop down?
For example, I have Shipments HasMany ShipmentItems HasMany ShipmentItemDetails. I added a second nested grid via RowExpand and Set Property. This results in the Data drop down showing Master (Shipments) and the 2nd Child (ShipmentItemsDetails) but not the middle child.
It seems if it were a page property it wouldn't be the exception.
Josh
For example, it's unclear when I can use ${data} and when I cannot
It is available only in templates.
I understand the unique naming requirement on nested templates. But instead of the magic property, could you not create a page property and then the collection would exist in the Data drop down?
No. The template context is different per item. The ${data} expression for the first item in a DataGrid is different from the ${data} expression of the second item. This is also how Blazor templates work. Heck I think templates in all platforms work via some "context" that represents the current data item.
This results in the Data drop down showing Master (Shipments) and the 2nd Child (ShipmentItemsDetails) but not the middle child.
The results in the Data dropdown show only page properties that Radzen knows to be of array-like type - arrays, IEnumerable etc.
Perhaps then the data drop down could be made context sensitive. For example, when manually adding a nested grid template, I must guess at the magic unique name ${rzNwModelsInventoryShipmentItem.ShipmentItemsDetails}
and hope it's correct cuz the designer says it cannot be found - even though it works at runtime.
And also the grid column editor breaks
I understand why it cannot be a page property because of row context, but how to make it not forget the data model at design time?
Why are you doing this?
In order to add a second nested grid. I’m simply copying the expression from the wizard and guessing at the name. Or looking in the generated page. Is there a better way.
I don't follow. Why can't you use ${data} as with the first child DataGrid? Are you trying to access the grand-parent data item in the innermost DataGrid?
I had no idea I could use ${data}. It works!
The first child grid (from wizard) uses the magic context name.
Please check the help article I linked before.
Thanks @korchev.
FYI - the designer still puts an error and column editor is still broken with ${data}.
I believe I read that was a known issue in another thread.
