Announcements
Attention for Customers without Multi-Factor Authentication or Single Sign-On - OTP Verification rolls out April 2025. Read all about it here.

How to connect to the inputChanged event dynamically

chetmurphy
Contributor

How to connect to the inputChanged event dynamically

chetmurphy
Contributor
Contributor

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.

 

 

0 Likes
Reply
Accepted solutions (1)
441 Views
3 Replies
Replies (3)

chetmurphy
Contributor
Contributor

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. 

0 Likes

chetmurphy
Contributor
Contributor
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.

0 Likes

chetmurphy
Contributor
Contributor
Accepted solution

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.

1 Like