This is a simple blueprint that adds an item to a List view.
It creates a simple User Widget (list item), sets a TextBlock value and Adds it to the List.
Below is an identical example but instead of adding to a list it is added directly to the viewport.
Hey. I did a small test. It turns out that the value of the text actually gets updated in the variable, but not graphically in the list view. Try looking into how to refresh the list visually. I’m looking into the same. The value is definitely being updated, but the listview is showing you stale values
This does not work well because the indexes get mixed up since the list will release and regenerate new entries when they disappear and come into view again. Can be solved with better indexing but that’s just not the way it’s supposed to work, is it now?
I also tried to override the interface function but that just gets ignored like everything else.
Your top two images failed to embed.
Could you post the second photo or elaborate how you are setting each generated element explicitly to the new value?
I figured out a way to update the TextBlock in ListView! I’ll explain it by using your example.
If you set your text in the Event Construct of ServerListItemWidget, it will work. In fact, if you create a custom event in ServerListItemWidget to set the text and call it from within the widget at any point of time, it will work. If you’ll try to call this custom event in some other widget, it’ll fail to update the list.
Your almost there @Everynone. What you need to do is call GetIndexForItem() on the widget your getting from the EntryGenerated Function. This will give you the proper index to feed into your data array
Your almost there. What you need to do
is call GetIndexForItem() on your
widget. This will give you the proper
index for your data array
Thanks for the comment but are you actually suggesting that child regeneration is the correct way to use the Listview widget? o_O No way, this is way too awkward of an implantation!
Besides, I haven’t checked in C++ but in BP Get Index For Item() returns -1 for valid children, so…
Hm, I added a comment to your message but you moved it? It disappeared. Some time ago I made it work OK with manual indexing since GetIndexForItem() returns -1 for valid children. Not sure about C++.
Besides, this surely is not the correct way to use the List view. Awkward much?!
I completely agree about the usage. 80% of the time I think it makes more sense to create custom solutions rather than figure out Epic’s intended usage. I realize why it returns -1. I told you the wrong thing, it wont work in blueprint that way… what you need is the underlying UObject index not the widget because the UObject array remains intact unlike the Widget array. I’ll look into it and get back to you
No worries, I know that Listview creates its own widgets and disregards everything else, that’s the reason it does not work. Because I believe it does not work as intended at the moment.
no it works perfectly for me in C++ because i can intercept the OnGenerate Function and get both the UObject and the Widget. im trying to think of how to do it in BP
Try OnItemScrolledIntoView - that gives you both the item and the widget. Then call getobjectindex on the Item not the widget. I avoid BP like the plague so its not my strongpoint
I do not have the project (I was proving the point in my original answer) and I am reluctant to set it up again since I know UMG well enough to tell when things are fishy. (or that the time spent setting it up and making it work is a poor payoff). It’s not the first time I’m hitting UMG limitations/bugs.
I mean, the very fact that the list view ignores the widget added to the panel and creates its own instance from defaults tells one a lot about the functionality. Whether it’s indented or not.
Lets say I want to add an instance of a widget to the list view dynamically. I will feed the list a fancied up child but that will get ignored because the list view will then create its own version from class defaults. So I need to find in the list and push the data back it again? No, thank you.
Don’t even get me started on trying to insert widgets into panels.
For the sake of clarification, this does absolutely nothing in BP, for example:
I am under the impression that this widget shouldn’t have been exposed to blueprints in 4.20. On the other hand, if this is the intended functionality, I do not wish to have anything to do with this widget
Agree with everything you said. I assume Epic did it that way for performance reasons when there are like 200 widgets in a list, but I hate it too. If I had the time I would convert to [Neosis][1]