I’ve done some testing and it seems that macros from a Blueprint Macro Library cannot be got from within a widget blueprint? Is this intended? I can’t find any documentation describing this as a limitation.
You’re right.
It’s to do with the chain of inheritance. A typical macro library inherits from Actor, whereas a widget inherits from User Widget.
Having said that, I don’t know the entire story, because you could easily write a load of math macros that are suddenly unavailable in widgets, for just this reason. Why should you have to copy all that over?
Maybe someone else has an explanation of this ‘segmentation’, or maybe it’s just to do with inheritance…
1 Like
Best plausible answer.
2 different people worked on those and never bothered communicating with each other. As such, the 2 systems never learned how to communicate.
How’s that for a stupid yet real answer? 
Widgets are a different access class in CPP and in blueprint.
You would need to duplicate the macro library, pick the relevant parent class, and correct any errors due to the parent class changing…
1 Like
can you do functions instead of macro? ie single exec path.
If so create function library and make functions.
Also widgets are not meant to have complicated code, and they pita to communicate with parent of a parent etc.
Same problem with functions, I think… ( function libraries )
Never had a problem communicating between them.
And the code in them has to get rather complicated if you expect to handle controller support.
You have to override the input and manage it via code to so so.
Never had a problem doing that either, except yes, in BP it’s painful.
What are you doing to communicate?
You can set the Owner and access from the widget.
Or you can set a variable and cast to the parent/solve a soft reference.
Doesn’t take much.
Thanks for insights everyone.
In my case, it seems like just copy/paste the specific macro I need to use for that widget is the simplest thing to do. It’s nothing complicated - just struck me as odd that there was this limitation but I didn’t see any words about it anywhere. But it did strike me as odd that the macolibrary derives from actor class, so I guess I could have put the two and two together.
When you create them dynamically, then make widget out of dynamically created items.
Like when you need to make list of items etc.
However i found that dispatchers and hooking all widgets to one in player controller or character makes everything simple.
Back on topic, imo. widgets in gui should only format incoming data and display it.
for two reasons:
- if you place all logic (besides formatting) in single place like player character or controller, on separate page, with macros etc. You have all gui logic code in single place, easier to maintain.
- you can create more “generic” widgets, for eg. single widget that display progress bar and some text. You will feed its instances with hp, mp or stamina or whatever, and it will be same blueprint code.
ps.
And you can create your own custom widgets, like add progress bar, icon, text. Create widget out of it, then add that widget as single item. So making those generic and without specific logic cleans up code. I know basic stuff, but people are searching those forums and get to old posts from years ago.
1 Like
@BIGTIMEMASTER Didn’t you accidentally try to use an Actor Macro Library inside your widget? As those won’t work - be sure to implement your global widget macros in an Object or UserWidget Macro Library.
1 Like
Makes sense. I am refactoring now and working on doing such.
Just tested and that works great! Lots of great insight in this thread which is helping me get my refactoring done a lot cleaner. But just to summarize, I think this is the most direct answer.
For future searchers: To use a MacroLibrary inside a widget, you have to set the MacroLibraries parent class as Object or User Widget.