Hello everyone! Iv’e been scratching my head the whole night with this issue and can’t find what i’m doing wrong.
The case is this: I have a menu that gets populated by a data table, containing information about each button for the submenus populated first, same class, fast to pure cast with a safety branch just in case (1), then i populate a widget switcher with a custom frame with a title, a button , a scrollbox, and a text in the bottom (2), and the submenu class from the data table populates the scrollbox(3).
So far everything works correctly about the switching functionality, but i need to show a hint every time i hover an option, and there is the issue. The hint is in the bottom of the frame that contains the current submenu, and i need to communicate the hovered/unhovered from the child (the submenu content) to the parent(the frame), but since they are created on construction, there’s no way to set a reference for an interface or a dispatcher without casting for each one, breaking the point of data driven population.
So far, iv’e tried interfaces and dispatchers, but they need a reference from the submenu (3) to it’s container (2) and i can’t find a way of pointing a reference to an instance on construction unless i cast to each to each one to it’s class, or sending information once in game because interfaces and dispatchers needs a target, which is null (the variable for the parent is there in each submenu, it’s just nullptr)
Any help or idea will be deeply welcome and appreciated.
Dynamic binding is where dispatchers shine the brightest. Bind when you add a widget to the switcher. No casting required. Here’s what I understood:
you have a switcher
you dynamically add user widgets to the switcher
you want those user widget children to communicate back to the widget that owns the switcher (you can also make it communicate with something else, ofc)
Do clarify if I got it wrong. There is no need to expose Root as you do, this is the precise use case scenario where dispatchers provide the cleanest comms.
Something like that. Everything works fine between 1 and 2 (top menu, switcher index and border) because they are created directly from the data table and are the same class, so i just point directly their respective parents with a pure cast if needed. The individual submenus (layer 3, inside the border) also work, i.e. i can already adjust all the values in game and load and set settings, and for the moment are hand taylored for each submenu because i still have to work on individual type of subwidget (slider type, dropdown, subtitle/reset/save section), but i can’t find a way to get layer 2 and 3 to communicate.
i.e. Because i only have one class beign added for a while in the loop, i can cast to get a specific item inside, and get out of the loop to continue adding other classes if needed.
If i get this to work, i can continue adding the submenus items dynamically because i’ll know how to handle different classes so i can just work with the data tables to populate as needed. In this example i’m working with the Settings submenu, but many others needs to be built based on data tables, like, level variations that will populate tables as they are created and this tables will generate the individual cards in it’s respective submenu, and they will communicate the variation manager the user’s selection.
So, before, i was populating the scrollbox directly from the main menu. I was using my main HUD to create the entire UI in one loop. Spent some amount of time trying without results, and changed my approach. Now I’m populating each border with it’s counterpart in the table, but still, doesn’t let me assign the bind to the widget i just created. Everything else is working normally, except i can’t make the hints work yet.
You’d need inheritance where the base widget class has the dispatcher. Assuming all those widgets are of different classes (are they?), you can re-parent them. If you hook it up with the base class:
Yes, they all are of different classes, and I reparented them to the border widget containing the dispatcher, used a brand new create widget node, and still get the User Widget output. As i said before, i was creating the submenus in the main menu in a single loop to avoid looping twice and getting the current index to populate the submenu inside the border. Now i moved the submenus population to the border itself and getting the index of the table by using the engine naming convention _C_? and getting the rightmost character, keeping out the last index because it’s the exit confirmation and there’s no need for a border like in the submenus. So the loop in the main HUD creates the buttons and a border inside the switcher, and when the border gets created, adds itself the content it needs from it’s index on the table and not beign forced by the Main menu using the loop index.
Had an Editor crash at loading the project late last night after not sleeping for almost 40 hours, so I went to bed and in the morning I had to move my UI folder outside, open the project, copy the folder back, disconnect all construction nodes on the conflictive blueprints and start to depurate one by one. Meanwhile I moved to another UI functionality (auto update input device type icons) to clear my head and try to find a solution for the menu dispatchers.
Here’s where i’m at with the menu:
I compare the title of the current frame (second level) to the text from the table, to populate the correct submenu.
Somewhere along the way i broke it, or it was already broken and i didn’t noticed, and it’s weird becase i tend to debug in almost every step of the way.
This is a really bad idea, it’s not reliable. If, for some reason, you must a use an ID system, create your own ID system. Give actors tags or give widgets Name IDs. And for something more in-depth:
Yes, in this specific case, but the idea is to use notifiers to send the data from a widget to another without knowing about eachother, to make a modular system and send data from anyone to anyone using events.
I’ll read about it and try to implement it. The more reliable the better. It’s for my own consumption, for my own ArchViz projects, and the easier, faster and more modular i can work in the end, the less headaches and debugging i’ll get, and can focus on the actual client’s needs instead of making deep changes to the UI/UX. As gamers, developers, and PC guys, we know what a setting or parameter might change if touched, but for the end customer of the product, hints and info (in this case) are a must because could be someone like us or a person without technical knowledge, and providing information on critical settings is important. Also, this is intended to show all kinds of info, like the player’s location in the floorplan, etc. and each submenu should talk to the info/hint text without knowing about the text existance, using a dispatcher, and the text needs any content on receiving the UpdateHint event.
Just to clarify - a fully fledged native tooltip systems already exists and is embedded into widgets. There are reasons why one’d want to create their own ofc.
You can now send their notifies to any actor / widget / component providing the signatures of the Dispatcher & Custom Event match.
Little can be done from our side regarding this bit. We do not see the full picture. Chances are it would take significant time to convey the details. However, feel free to rubberduck in public until it makes sense. It works surprisingly well.
So the solution after reparenting was to make a pure cast to the parent widget class and make a safety branch just in case and for debugging. It’s working now. As for the comparision method i just used the row name as a name ID and passed it to every widget created from the table as a Name variable and now everything is on sails))))
