Hello!
I'm having trouble creating an item and refreshing the binded dropdown that contains the list of these items. The item can't be seen in the list after creation, but it can be found when filtering. Also the dropdown Value is correctly set, as it loads the id of the created item.
As far as I can see the DropDown is bound to siDocuments populated on Page Load and you execute Load after add. Everything looks correct. Can you refresh the page completely from the browser and check if the item is visible?
Yes, if I refresh the page the item becomes visible. I'm pretty sure everything is setup correctly... the only catch is that both forms are dialogs. Novo Vínculo de Documento is a dialog from another dialog, and Novo Documento is a dialog from Novo Vínculo de Documento.
I rearranged them so that Novo Vínculo de Documento is a page and Novo Documento is a dialog, and it worked. Maybe there's a bug there, I don't know. Right now, nested dialogs seem to not work properly.
Invoking StateHasChanged() might help
I added await InvokeAsync(() => { StateHasChanged(); }); and the problem persists.
I'll try to replicate the problem locally to see what's going on
I've added Add Order button to open Add Order as dialog in already opened Add Order Detail with await Load() as Then:
In your third image, you're seeing the item while filtering. I can do that.
What I cannot do is select the item without filtering, because it does not appear in the list originally.
It shows up only when filtering.
Adding this in case it helps someone. I could not get the dropdown to see any new items if I tried to reload the entire collection that the dropdown was bound to. However, if I simply added a new item to the collection (colSurveys.Add(objSurvey)
it worked.
I recently ran into this issue as well (using Blazer Server). Although calling await Load() worked to reload the dropdown data, this wasn't a good solution for me as it cleared the form of any values the user may already entered.
TLDR; the fix in my situation was to execute the following bit of code in the event handler after reloading the data:
${getApplicationServerTypesResult} = ${result}.ToList()
This is a pattern I've seen used elsewhere in Radzen-generated code, perhaps for the same reasons (I've not looked at those cases closely enough to say for sure).
Forcing the materialization of the dropdown-data query (via the call to ToList()) appears to be necessary because the property setter for the data does an equality check against the existing value and, if equal, doesn't set the new value.
if (!object.Equals(_getApplicationServerTypesResult, value))
{
var args = new PropertyChangedEventArgs(){ Name = "getApplicationServerTypesResult", NewValue = value, OldValue = _getApplicationServerTypesResult };
_getApplicationServerTypesResult = value;
OnPropertyChanged(args);
Reload();
}
Makes sense, as you don't want those OnPropertyChanged() and Reload() methods to fire if the property value hasn't really changed. The problem is, when calling the Radzen-generated service class's GetMyThings method without any arguments (the Query parameter is optional), the method simply returns Context.MyThings.AsQueryable().
Which, in the case where we've already loaded the Razor component and we are now trying to "reload" the dropdown data, means we get back a reference to the same instance that we already have stored in our component's instance variable for that collection of data. (DbSet's AsQueryable() extension, it turns out, doesn't return a new instance, but simply the same instance typed as an IQueryable<T>, essentially analagous to an explicit cast.)
You can verify all of this by replacing object.Equals() in the property setter with object.ReferenceEquals(); you'll see it still evaluates to true (for this particular scenario). I'm still getting familiar with the Razor component lifecycle, but I believe this is because all instances in the object graph for the component haven't changed because, well, we still have the same instance of the component.
Which is why materializing the query solves the problem; the equality check in the setter now evaluates to false, because the materialized list of items no longer equals the initialized, unmaterialized query, and the property value gets updated (and in turn, so does the bound dropdown).
This is perhaps a bit of an edge case (though in my app it occurs in several places), and the fix is simple enough, but perhaps the Radzen team could weigh in on whether this behavior is working as intended or could be considered a bug?
I specifically created an account to upvote this comment. Thank you so much.