Here is the latest macOS build:
1 Like
Thanks. The OP mentions a case where the nested context of a button points to context of last expanded parent - seems relevant. I'll try your next update.
Unfortunatelly, this release candidate behaves very unpredictably with unexpected crashes
Can you check the log file for errors?
There is nothing in the log file except for information about radzen installing.
After a crash and reboot Radzen, even work projects do not start
console output:
Error
Also, there is an designer error:
It seems there is a dotnet process running in the background preventing Radzen to work properly. Please close Radzen, kill all dotnet processes and start Radzen again.
Of course I did, but this does not solve the problem of the fact that the Radzen error appears again
Just test your previous sample with nested accordion and check the parent page.
Also check the behavior of the accordion in runtime (collapse of all items)
Can you run the project? Is the error only in designer?
No, project not compile.
The designer killing yourself automatically after about 5 minutes, even if nothing is done
Update detection service is disabled
Ok. Use the official release instead the latest build - Iβll try to reproduce and fix reported problems tomorrow.
1 Like
I was able to reproduce the design-time rendering error with RowSelect (fixed immediatelly) however everything else worked as expected.
No crashes, application compiles normally and Accordion expand/collapse works runtime:
Please zip your entire application and send it to us at info@radzen.com. If the zip is too big you can use sharing service like Google Drive.
Thanks! I will wait for the official release, since the main work is on the windows
Well, or you can lay out a build for windows
There are 3 tables:
Orders {Id, Order value}
Packs {Id, OrderId, PackName}
OrderDetails {Id, OrderId, PackId, Value}
We build such a pattern of templates:
Orders-> order's packs groups-> order details
Receiving orders from a method:
protected async System.Threading.Tasks.Task Load () {
var getOrdersResult = await GetOrders ();
getOrders = getOrdersResult;
}
public async Task <IEnumerable > GetOrders () {
var query = from parent in Context.Orders
.Include (x => x.OrderDetails)
.ThenInclude (x => x.Pack)
select parent;
return await Task.FromResult (query);
}
Order data binding: $ {getOrders}
Data binding pack's groups: $ {data.OrderDetails.GroupBy (x => x.Pack) .Select (x => x.Key)}
Auto-type detection no longer works here and you must manually set the TItem = Pack attribute and add columns, but oh well.
I look, while everything is wonderful:
Next, the template for order details
The parent order context must be visible to all child templates and we can use it.
Binding: $ {data.OrderDetails.Where (x => x.OrderId == order.Id)}
Here data is the context from the second parent (pack)
order is the root context.
Everything becomes sad here, a designer error appears in the entire template tree, except the root, but the application compiles and works fine.
Providing a sample app would allow us to try supporting this case in design time.
Next.
Here is layout example:
The onclick event handler of the button of the third nested template is automatically created and refers ONLY to the parent context of Order's packs
Click = "@ ((args) => Button0Click (args, pack))"
But how to get the root context of Orders?
Manually this is done simply:
Click = "@ ((args) => Button0Click (args, order))"
The order context is at the root of the template tree and may be an argument to the call.
But Radzen strongly disagrees and does not allow to do so.
How to get the root context of a template?
Radzen is trying to be smarter than what is required of him, can you turn off the automatic determination of contexts, event handlers, and method calls by shifting this to manual control? All that is required of Radzen is visual markup and css. From these constant problems, project development is severely inhibited.
Of course there is a workaround - put the button in the RazdenHTML component:
<RadzenHtml>
<RadzenButton Text="Button" Click="@((args) =>Button0Click(args, order))" >
</RadzenHtml>
This will work at runtime, but the designer will just go crazy and will not see any handler or context
In general, it surprises me - why do you allow the release of a product containing such problems? Each new release is a new problem. Nobody makes projects on Radzen, more complicated than one nested template? The main leitmotif according to the forum - "we will fix it in the next release"
It seems that we all participate in beta testing, paying $ 600 for it
Hi,
We are sorry that you are not satisfied with Radzen and Radzen.Blazor components even thought we tried to fix all reported problems immediately. We decided to issue full refund of your payment.
1 Like
Iβm completely happy with the idea of Radzen as a visual markup editor, since this is a very tedious task to do it manually, but he has obvious problems with handlers.
Thank you for the offer to return the funds, despite the fact that these were my personal funds, but I would prefer the continuation of the license and operational support! Itβs far more important for me to have an effective development tool
My take away: there is a problem with context for nested templates and @enchev & @korchev are working hard to address it. For the record, I find the common theme from users is amazement at the near immediate response resolution and frequent release cadence. Keep up the great work guys!
1 Like
$0.02 more: If Radzen is doing anything too much it would be the WYSIWYG designer. My opinion is that drag n drop doesn't make forms over data easier. Everything could be done in an hierarchical outline-style designer plus a preview button to show results rendered. Maybe this would relieve you of the added complexity of maintaining realtime rendering in the designer which I gather differs from runtime rendering in some ways(?)