it works for users who symlinked their blenderbim/bim folders to git repository or installed blenderbim from release created from makefile
https://i.imgur.com/mEBH9I7.png
Use an is_registering check to only run the on_register once.
Rename setDefaultProperties to load_post to better reflect what handler it is.
Unregister our custom scene panels upon addon activation.
Move aprops getting to tool.Blender because it is a bit complex. Also, aprops may not be setup until load_post is called, so the len() check protects against that.
Unlinking an element recreates a new blender object so the active object would be lost, jumping the properties to the scene panel which was slightly annoying
1) When you search not from the SCENE properties blender creates some kind of phantom area to check search results. As this area is not present in `context.screen.areas` it was resulting in the error below.
2) After 949a2bb search in scene properties was limited to currently selected tab. Given the amount of tools we have in properties and native blender approach for searching across all available sections in properties, it seems reasonable to make search work across all tabs.
Console error was:
The error was
Python: Traceback (most recent call last):
File "\3.6\scripts\addons\blenderbim\bim\ui.py", line 281, in draw
aprops = context.screen.BIMAreaProperties[context.screen.areas[:].index(context.area)]
ValueError: bpy.data.screens['Layout.001']...Area is not in list
After 949a2bb printing happens not fron N-panel (which is part of viewport) but from scene properties - so current context doesn't have region_3d anymore.
PS The same issue was there all along if you'd try to print the drawing from Camera Properties tab.
Previously if you change `HasUnderlay` in pset it caused errors because camera properties `has_underlay` wasn't updated.
Still some work need to be done for updating keep camera properties in sync with pset - probably we can should call something like `tool.Drawing.import_drawing()` on EPset_Drawing edit
Currently, the undo system works by wrapping the execute operator. What was not considered was that execute() isn't the only entry point to operators. Operators can be invoked. If an invoked operator calls a bpy.ops.bim.something in its invoke() function, then bpy.ops.bim.something will start and finish its own transaction, and then when the invoke finishes and finally runs execute(), another transaction will be started and finished. This means that we get at least one extra transaction logged (one per any call to bpy.ops.bim.foo in invoke()).
This mismatch of number of transactions and undo stack means that when the user presses ctrl-z, the undo doesn't actually occur. This leads to a sync bug.
To be safe, all IFC invokes must be wrapped. This will take some time to review so expect another commit soon.
Dion Moult
