Gui.try_get_node that doesn't throw an error when node is not found

Questions
#1

Would it be possible to add a variant on gui.get_node so that when it fails to find a node it returns nil instead of throwing an error?

#2

Can you describe the use case where you need such a function?

#3

A collection of animated buttons that each differ slightly by the components they are composed of, but each component has a specific animation. A bunch of these button pack guis (think pop-quiz) all ran by a single gui_script. You access the count of these buttons then you iterate through all of them and try to animate every component appropriately, if the component isn’t there, you should be able elegantly to move on. This is solvable by having a table that describes every button in every button pack, but then editing actual gui has to be coupled with editing the table that describes those buttons.

#4

Could you try wrapping the call in a lua pcall, something like;

local exists = pcall(gui.get_node, "some_node_id")
if exists then
	pprint("Node exists")
	--do stuff
else
	pprint("Node does not exist, carry on..")
end
3 Likes
#5

I need to remember this. Might come in handy.

#6

From the Lua manual; https://www.lua.org/manual/5.3/manual.html#pdf-pcall

Reading the manual you should actually be able to do something like

local exists, node = pcall(gui.get_node, "some_node_id")

If the node exists, node will hold a ref to the node, otherwise it will contain the error string.

4 Likes
#7

pcall would solve the problem but I still don’t really understand the need to check for the node? It’s not like the collection of animated buttons is created completely at random and outside of the developers control. A data driven design would allow you to know for which buttons that there are animations and how to animate them.

1 Like
#8

Each collection of buttons is created by hand in editor (not by code). From this comes the risk of desync I mentioned, where appropriate tables become meta-data that needs to be updated manually. This would be ok if gui items could have go properties. At least the data could be in a single place then, but otherwise it’s sspecially risky if you imagine a development pipeline with multiple developers where one developer group has only keyboards and another has only mouses (sort of comedic, but a good generalization of developer roles/skills sometimes). So there is no NEED in that this issue can be worked around. Anyway, it’s already solved so the feature exists.

#9

An option is to run a python (or what have you) script and gather the relevant button setups and save it as a Lua table. Check out DefTree: A python module for editing Defold files

3 Likes