IndexError when loading config after item renamed in FreeCAD

[MisterHW]

There seems to be a problem with identifying objects by name, or rather when FreeCAD-OpenEMS-Export loads object names from the config file and they no longer match the FreeCAD project:

10:43:15  Traceback (most recent call last):
10:43:15    File "C:/Users/username/AppData/Roaming/FreeCAD/Macro/FreeCAD-OpenEMS-Export/Export for OpenEMS.FCMacro", line 3996, in loadCurrentSettingsButtonClicked
10:43:15      freeCadObj = FreeCAD.ActiveDocument.getObjectsByLabel(itemName)[0]
10:43:15  IndexError: list index out of range

The objects simply vanish from the treeview and the user is not notified beyond an error showing up in the report. One could insert placeholders that ask the user to re-assign the item in question and to document that it even existed.

It would be better though to use a global unique identifier that persists between the macro sessions.

From the discussion over at https://forum.freecadweb.org/viewtopic.php?p=480644#p480644:

for o in App.ActiveDocument.Objects:
    print("guid key: {}_{}".format(o.Document.Uid, o.ID))

"this gave me a unique id even for multiple documents and it works on document reload, and it keeps the same even on copy the document or save as the document. For me this seams similar as every FreeCAD object would have its own guid. For sure if a document would be copied with a file manager objects in both documents would have the same one. But if a object inside a document would be copied it would work and even if multiple documents are used all object identifier would be unique too."

A previous post, also from over a year ago, mentions that o.ID would change between reloads. For unique IDs to work in conjunction with FreeCAD-OpenEMS-Export consistently, objects would need to have persistent guids.

[MisterHW]

closing as issue has been addressed in commit 7b6232e3363b154cb782e40a4e547b795ade0e8c

• FreeCAD name used as unique ID (the "name" displayed to the user is merely the FreeCAD object label which can change, and changes are propagated)
• loading process was extended to handle missing objects

Future issue: Proper handling of broken object associations due to need for redo / undo support has been identified as a follow-up issue and will be addressed in another commit (association needs to be remembered in the background but shown as disabled or hidden).

Test case:

• FreeCAD object is associated with a simulation item, appearing as a child node in the rhs object association tree
• FreeCAD object is deleted in FreeCAD while the form is still open
• documentObserver event triggers updated and the broken association is detected. In the course of that, the item is flagged as "broken association" and treated accordingly