Steps to reproduce this issue:
- Create two properties (I tested in a Perspective view’s
root.custom properties). I called them
test1 to be bound to the property
test2, and likewise set
test2 to be bound to
Immediately after performing this, the binding editors might still open, but it breaks after interacting with the Designer for a while, such as switching selected objects so the Property Browser shows that object’s set of properties, and then switching back. When trying to edit the bindings for
test2, Designer throws an error, “Unable to open the Binding Editor” and the Binding Editor window shows a blank white screen.
I was unable to close these error/blank Binding Editor windows and had to forcibly kill the Designer and re-open it.
I would expect that to happen in any version of Ignition. To me, it seems inaccurate to call that a bug.
Within any powerful framework that allows you to build with minimal restrictions it will always be possible to shoot yourself in the foot on purpose and also by mistake.
It still shouldn’t crash the software. If I had saved before trying to edit the binding again, my project would be completely hosed and I’d have to recover somehow.
I think it’s a bug.
How would Ignition detect when a user creates an infinite loop that consumes all available memory? How could it recover from that situation with no resources available?
I’ve lost work before because of mistakes I’ve made and I don’t fault Ignition for that.
I’m not saying that it wouldn’t be great if they could build in protections against such situations. Anything is possible, but where do you draw the line?
You probably could have recovered the project by editing the json file for that view to remove one of the bindings. It wouldn’t necessarily be most user friendly route, but it would have been recoverable.
To an extent I do agree, I would like to see the designer be able to handle the issue well enough to allow that binding window open and remove the binding, but I don’t see this as a bug as much as a feature request since this particular case shouldn’t have happened with bi-directional bindings being an option instead of creating this loop.
We’re already aware of the potential for infinite loops (and recursive loops and a whole bunch of other why-would-you-do-that loops). We’re looking into ways to mitigate the effect those loops have on the Designer, but due to the ability to change values at runtime there is absolutely no way for us to prevent loops 100% of the time.
Creating circular bindings should not “lock-up” the Designer, and that is the purpose of the existing ticket. That being said, creating those types of bindings in the first place is not smart design and should absolutely be avoided.
That being said, creating those types of bindings in the first place is not smart design and should absolutely be avoided.
You’re absolutely right. I encountered this by accident (got confused as to which property’s bindings I was actually editing, didn’t think to look at the title bar…) and ran into the issue and figured I’d report it.