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 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.
The Item added to the viewport is properly updating the text. When added to the list view it is not properly updating the text.
Is this a bug or is there a proper way to initialize text?
The text only needs to be initialized once on creation.
If you use an event tick to print the value it is Text Block instead of the desired set value.
Ignore this post, a load of gibberish here. See Flemmard’s entry instead.
The right way to do it:
This seems to be rather buggy at the moment.
When the list view creates a user widget object from its entry class, it only cares about its default variables values and will refuse to update.
So far, the only way I’ve found is this hackaround and even this does not really work that well:
Create widgets and feed the list an array of text:
In the List View widget, set each generated element explicitly to the new value:
It sort of works, sort of:
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.
1 Like
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?
Done. Thanks!
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.
Could you demonstrate how you populate the ListView with several entries, each with unique text?
This is not correct. The blueprint I posted is setting the text inside the construct event and it does not work. I’m not following.
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
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
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?! 
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
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]
[1]:
Thanks for trying but that’s not the point.
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 
Again, thanks for looking into this! Good to know this is working in Slate.