Widget: ListView (and relative types of lists) do not behave as you would expect

General Feedback & Requests
1

I’ve been working with the ListView, and have had to create a lot more extra blueprints (and sometimes doing it in a way as a programmer I would never think to do).

For example…

  1. I should be able to create my widget list item, set its properties / text / etc, and prepare it before I add it to my list.
  2. I shouldn’t have to listen for the item to be created to finally make modifications to it.
  3. I should be able to talk directly to the listview item when I need to make changes to it, rather than iterating the listview and guessing what to add.
  4. The item I add to the list should be able to react to events and update its own properties / text to reflect back to the listview (why doesn’t it?)

Here’s an example screenshot of how I am having to work with the Listview, which I don’t quite yet understand why it works only this way (I spent a lot of time trying to figure it out).

In the screenshot you can see, I preconstructed and “added” my list view items in preparation to have a specific number of items (creating basically array slots empty for being set).

But in reality, I would have expected to construct my listview object (line item) before using “Add Item” to the list view.

Annotation-20200419-135330.jpg
Annotation-20200419-135330.jpg1507×648 189 KB

Aside from that, I’ve also tried sending in important information to the list view object (line item) to retain so that when I update information I could simply call on an event to tell it that something has happened (in this case, I killed a monster, do I have a quest that shows I have now 5 of the 10 monsters killed, but I can’t do that).

When I access the line item and tell it to update, it has lost all recollection of everything I sent the EWC… It’s almost like it doesn’t want to behave like a real object, retaining information.

It’s just very unnatural as I have a strong programming background, but I would expect to articulate this into these flow charts. I would gladly move to C++, but I really don’t have enough memory left in me for another language since I program for a living and my stack is more based on C# / PHP / JS / ES6, etc. I just don’t have the capacity for a new language, and C++ is extremely strict.

I just wish this were easier - everything else so far has been similarly easier to articulate in a programming way, except this one - it just seems like something got left out and is confusing for no reason.

Hopefully this comment helps. I just don’t think it should be this complicated, and everything should be treated like an entity, regardless of where the entity is displayed / added to (such as the parent listview).

1 Like
2

I’d like to continue on this thought.

I think I use ListView differently than you described @Groot_Llama.
But I think the point here is that there is a lot of confusion around this solution.
I think most users expect something else. I bet this question has a lot of views.

Confusion #1:
You define an Entry Widget Class in your ListView.

What I expected from this was: I create new widget objects, modify its properties and them simply add them using ListView’s AddItem.

Confusion #2:
You can create instances of the Entry Widget Class and then add them ListView’s AddItem.

AFAIK you are not supposed to. You are actually supposed to add a data class derived from UObject with exposed parameters.

Solution?
I don’t think you should be able to do this mistake. Maybe AddItem should have some kind of check or only accept a specific class type.

Confusion #3:
There is not a dedicated help chapter that describes the way this is supposed to work.

Solution?
Add a help ListView help chapter.

That being said, I am fine with how it works, now that I understand it.
I think it’s good to separate data models and presentation. But I wish it was easier to grasp when you use it for the first time.

3

The list view is used to display large collections of items (thousands) while only using as many widgets as you have visible rows on screen, repurposing them. This is why it works the way it does.

If you don’t need this then throw a vertical box in a scroll box and call it a day.

1 Like