That guy and I are the same guy.
The main issue is that I realized the
guy is generating multiple copies of
the same widget, and using their
object reference to implement the
code.
With my case, I would be generating
different widgets in different ways
(unlike the guy’s solution of creating
multiple copies of the same widget),
all still behaving the same way as the
guy have shown.
It was just for the convenience of the example. It does not matter what those widgets are for as long as they’re sitting in the canvas.
Since you can’t create a widget
blueprint child apparently (or I don’t
know how compared to making child
actors for example) I’m stuck trying
to figure out how I can have multiple
widgets behave the same way and how to
reference them in the main widget (the
monitor of the computer actor) in
order to implement the guy’s code.
You can but the feature does not work the way it works with actors (it’s not proper inheritance, sadly). You can reparent widgets:
This means that the children will inherit variables and functions but not the hierarchy…
generating multiple copies of the same
widget, and using their object
reference to implement the code.
Instead of dispatching a widget of specific class - Grabbed Window, dispatch User Widget instead - we really only care about it being a valid canvas slot. Essentially this…
…should be User Widget to make it type-agnostic. And Grabbed Offset can be added as dispatcher data.