Wouldn’t UListView have been a better widget than UScrollBox to handle the server list?
From what I have read, ListViews allocate resources dynamically but are more difficult to work with and harder to navigate using controllers over the ScrollBox, which loads all entries at once.
For the purpose of the course, it probably doesn’t matter too much - the main thing is to get a UI offering this functionality.
I guess it is down to preference but from what I can tell, low entry counts work better in UScrollBox and larger lists (100’s or more) are best with UListView. Having a list of 100s of servers/games to join isn’t practical really so in my mind, this was probably why the ScrollBox was chosen.
Ultimately I say this is down to preference and purpose.
I agree that UListView is the way to go for huge list, because it wouldn’t be practical to allocate so many row widgets that ultimately invisible anyway. No question there.
I don’t understand why a UListView would be harder to navigate with controllers.
… I realize that my original question is leaving a bit to desire. Initially I wanted to ask via an older thread that was already talking about the subject and thus I ended up leaving that part out of the new thread. Sorry about that. 
My question is related to the handling of the selected item. A UScrollBox does not have any notion of selected item, and thus we have to implement it ourself. This leads to bugs. For instance, in the lecture’s code, when the list is refreshed, MainMenu does not reset the SelectedIndex, not does it tell the newly create row that it should show highlighted.
UListView on the opposite already handles all that for us, and presumably has most of those bugs ironed out.
So in that light, would the UListView be better suited for our needs, regardless of the number of rows?
Please bear with me on this one. Having to do this yourself is not a bad thing. A number of grad students I’ve hired recently have zero ideas of what basic constructs are or how they work. Modern languages and, in this case, frameworks often give the user such useful things such as lists and often variants of them that suit different situations. So, to demonstrate how selection works and so on is not a bad thing - there may be glitches also not a bad thing because the second skill lacking in most graduate developers is they cannot debug code because college teaches them using rote methods.
So, should a UListView be used is a different question to could a UListView be used. Could? yes. Should? Good question.
I would argue not for the reason it forces students to think how things are being done. There’s probably assets in the marketplace that will do a lot more for a lot less effort too.
Would a UListView be better? Again, it depends on what you want to get out of the course. Honestly I am on the fence but as an exercise on understanding how things should work, I would say no. Learn to do it yourself.
Plus, if there are bugs, it’s good for people to have to troubleshoot and fix the bugs.
Apologies for the long-winded reply here but I have to usually spend typically 6 months or more getting software grads to a point where they can actually do basic coding because their degrees don’t teach them anything.
This here may not be 100% accurate but in my looking into the UListView control, I found quite a number of articles saying that it was difficult to get gamepads, for example, to control these controls. That’s a lot of the word control(s) 
Anyway, Since I saw it referenced many times I figure there has to be some truth in it.
Hope this clarifies my opinion of the UListView vs UScrollBox.
1 Like
To a degree I agree. But this is also an Unreal Multiplayer course. It has already digressed a bit by teaching how to do menus (note below). Teaching how to do a selectable list is stretching it, that’s not even an Unreal Engine question anymore. Similarly, while the marketplace is an option, it’s not Unreal proper anymore.
It’s like when learning C++, one should learn STL before pickup new containers from github. At the same time, I don’t think I should learn how to make my own std::map when being taught C++.
Like you said, it depends a lot of what one hopes to get from those lessons (for both teachers and students). Personally, I’m looking to get a solid base to build on. I want to learn how to use Unreal at its best. I want to learn the ideal/proper ways, before I take shortcuts for reasons of performance, simplicity, etc. If there are alternatives, I’d like to be told what they and their tradeoffs are, so later I can choose what is right for me and my projects. And I’m here to try to benefit from your experiences and knowledge in the field, I’m not here to be thrown to the deep end to see I can float.
[Note: the menu part was useful info, I did learn a lot from it, but that should have been part of the Unreal C++ course IMHO. After all, it has nothing to do with multiplayer and the course started by stating it assumed a basic knowledge of Unreal and rare are the games without a main menu]
“DIY” does not need to mean “reinvent”. There is such a thing as “standing on the shoulder of giants”. Like I said just above, at this stage, I’d like to learn the right way to do things, to get a solid foundation that I can build upon and/or fallback to for my own projects. There will be enough to learn and discover by myself when making my own game I think, that I shouldn’t need to do that as well when being taught Unreal.
And this is not an interactive class either, it’s not like you or the instructors can correct my wayward ways later, which makes it all the more important to learn the proper ways now.
I’ll take your word for it, but it’s still hard to imagine. I don’t see why there should be any difference. Maybe they are talking about some of the more advance feature UListView, e.g. multi-selection?.. hmm I guess the advanced features could also interfere with the basic ones… maybe they use the same control scheme to control the controls (
) for single and multi-selection?
Anyway, I guess I’ll have to judge by myself once I start on my own game.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.