No problem, if you want to experiment with the List View instead:
- create an Object class blueprint in the content browser with an exposed text variable - it will be used to store data in the list view, called Entry Data below.
- once you have it, you can do this in the wLogLine’s class settings:
The Implemented Interfaces bit on the left is the critical part here! It allows you to pull the data from a list view object and assign it to the widget’s variable. The wCombatLog’s List View widget below will then need its Entry Widget Class set to the above-mentioned wLogLine:
Now, instead of creating new widgets, you construct Entry Data objects and push them into the List View.
From now on, the List View handles the lifespan of the widgets it creates. Even though I have 200+ entries here (after mashing the spacebar like a madman)…
… the list view displays 12 widgets and holds around 20 active at a time. So, having a potentially huge list is not that much of a hindrance and / or performance hog. Not sure about the memory footprint but it should be be lower providing the widget lines are complex enough.