Hi Ioannis!

I used an existing job in my development workspace to give it a try. Here's my test scenario:

• 1 job with 2 AC parameters (normal one returning array [1,2,3,4], and another one referencing this first one). Both multi select parameters.
• When I click with my mouse, changing the options in parameter #1, the parameter #2 gets updated as expected
• The ID of the parameter #1 is multiple_select_choice-parameter-5757281551183_
• Doing the following in my JS console changes the parameter value: jQuery("#multiple_select_choice-parameter-5757281551183_").val('2')
• The parameter #2 is not updated
• But typing the following in the JS console triggers the update in parameter #2: jQuery("#multiple_select_choice-parameter-5757281551183_").trigger('change')

So I assume you can trigger the parameters changes programmatically too. Does that help? Is there any other way I can try to reproduce the issue? Maybe I missed something from your current scenario, if so feel free to update the issue with some example or screen shots and I'll give it another go.

Cheers
Bruno

So what kinow suggested works. Thanks!

However, the programmatic update of an Active Choice parameter via javascript suffers from the luck of a stable parameter element identifier. Every time the configuration is updated the div id changes.

Preferably, we will generate a stable element id for the formatted HTML element that the AC parameter generates and then use it to get the AC parameter ID dynamically.

So, if we provide each of the input boxes generated from ACRR_1 and ACRR_2 (referencing ACRR_1) in the example above an id lets say id1, id2 respectively, we can use the following pattern:

document.getElementById("id1").value = 'InputBox1_Value';
//now get the Active-Choice Reactive Reference ID programmatically-avoids lack of stable ID issue
parentId=document.getElementById("id1").parentNode.id
//the next line triggers an update to the ACRR_2
jQuery('#'+parentId).trigger('change')

This strategy allows one to use javascript to update Active Choice parameters and cascade these changes to other AC parameters that reference them.

We are providing a reasonable workaround but this is probably not a bug in the first place, but rather the expected behavior. After a programmatic value change we have to* trigger an on change event* for the new values to cascade to other AC parameters that reference the original parameter.

Closed as not a defect