Fusion API and Scripts
Got a new add-in to share? Need something specialized to be scripted? Ask questions or share what you’ve discovered with the community.
Showing results for 
Show  only  | Search instead for 
Did you mean: 

How to connect to the inputChanged event dynamically

Message 1 of 4
188 Views, 3 Replies

How to connect to the inputChanged event dynamically

I am able to successfully add dynamic inputs and they work as expected, but so far I have not found a way to connect to the event changed handler.


The dynamic inputs are being created in my InputChangedEventHandler so eventArgs are Ptr<InputChangedEventArgs> which does not provide access to inputChanged command  directly.


I have tried using the command object obtained from eventArgs->inputs()->command() and that works for the tab via "APITabBar" id, but it does not work for the dynamically added inputs.


I am starting to think that it is not possible to add an input changed event handler while handling an input changed event and that I will need to create the possible inputs in the create handler and toggle their visibility on and off.  I don't like that solution, but it looks doable with the downside of adding additional complexity to my code.



Message 2 of 4
in reply to: chetmurphy

Duh... I just realized that the solution likely lies writing the creation handler(s) to be idempotent and then calling the CommandDefinition execute whenever the UI needs to change.


I am going to see if this works. At least it seems like this solution would fit within Fusion's guidelines. 

Message 3 of 4
in reply to: chetmurphy

CommandDefinition execute() does cause the UI to be recreated even when called from inside of my InputChangedEventHandler.

Implementing 'idempotent' is going to harder to implement since it appears that execute() clears the UI. So that means that the UI state at the time of calling execute() will need to be saved and restored as it is recreated.

Message 4 of 4
in reply to: chetmurphy

While CommandDefinition execute() does cause the UI to be recreated, restoring state for the CommandCreatedEventHandler is not possible for the SelectionCommandInput. So selection state would have to be restored using another event - most likely using InputChangedEventHander and that is not ideal.


On reflection I have concluded that dynamic UI should be limited to hiding/showing inputs. In addition, and more important when you find yourself considering dynamic UI as a solution you need to refactor your solution.


In my case I was trying to implement multiple commands within one command in an add-in. So I will be switching to a tabbed toolbar UI which looks like it will be a perfect fit.

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk DevCon in Munich May 28-29th

Autodesk Design & Make Report