I was just thinking about a better way to set text in a widget table so that you don’t have to hook up 10 times the same node just with different inputs. Right now I have a simple crafting table inside a widget displaying the “have” and “need” of each of the 5 available categories. Updating these numbers is not the problem, but I don’t think this is very efficient - or at least I hope there is a better way that I am just not aware of.
Expose the variables on spawn won’t work as the value change is tied to event “On Hovered”. I could create an array of all text fields in order of the struct info, but how would I use the “for each node” then?
Wrap each entry in a user widget and have a custom event inside set the fields (must be done only once and, also, if you ever need to change the font / visuals, you also need to do it only once rather than 78 times in 12 menus…)
Do note that I do not fully understand how your data is structured and where it’s coming from, so the above may not be 100% accurate, ofc. But that’s the gist - rather than working with native widgets, you encapsulate multiple natives in a user widget, and update that instead.
Widgets also support inheritance but it’s somewhat weird; you can get away without it unless you need really complex UI systems.
I have a column with 20 rows, I have
to manually plug all 20 rows into the
array
You could query the container for its children (like in the example) → cast → Add to Array. Now that you have an ordered array, perhaps you could structure the data you wish to pipe in accordingly:
I would have 3 columns x 5 rows = 15
inherited children in one single
master widget. Will the performance
drain upscale accordingly?
Very unlikely. If you had 150 widgets, each with a complex translucent material and needed to update them every frame, you’d drop a couple of frames, maybe.
Thanks very much for the detailed answer! The data is called once the widget is constructed and the update is based on the mouse movement so no need to cast - but I am very happy that this concerns you
I understand the logic behind adding the children to the grid - you are adding rows, I would need to add columns but that is pretty straight forward. Your approach also tidys up the entire blueprint very nicely!
The probelm with this, though, is that if I have a column with 20 rows, I have to manually plug all 20 rows into the array and manually assign all values to the select. This sounds like manual work that should be done automatically…
May I ask for your opinion on the following?
If I make a child for each and every cell in the entire “spreadsheet”, bind the value to something exposable on spawn and do some math to allocate the proper text, then I would have 3 columns x 5 rows = 15 inherited children in one single master widget. Will the performance drain upscale accordingly?
That would indeed work, thank you kind sir!
Yeah, I was also thinking about restructuring the input data and now I know how
Also great to hear that widgets won’t drain too much performance.
