Community
Participate
Working Groups
When used from withing the IManagedOptionvalueHandler#handleValue() method: Modifying the value of a string option via ManagedBuildManager.setOption() does not refresh the corresponding GUI object (textbox). It is only refreshed when doing something else in the GUI, such as switching pages. I found that if you have a checkbox on the same page and check it, then the string field is refreshed. If you do the same on a boolean option, the GUI object is refreshed correctly. You get the same problem if you use IOption.setValue(string) instead of ManagedBuildManager.
Update: On further investigation, the circumstances of the GUI field not updating are slightly different. The GUI option is not updated if it is the currently 'active' object (has focus). This happens regardless of it's type (boolean, string etc.)
Could you please provide any scenario to reproduce a problem ? I cannot imagine any situation when widget value is changed from outside _when_the_widget_is_visible_and_active_. Of course, it can be simulated programmatically, but does it have any relation to reality ?
> Could you please provide any scenario to reproduce a problem ? > > I cannot imagine any situation when widget value is changed > from outside _when_the_widget_is_visible_and_active_. > > Of course, it can be simulated programmatically, > but does it have any relation to reality ? I guess a scenario for this would be to have a page with both a boolean and a string option, and whenever the boolean option changes its valuehandler changes the contents of the string option?? Problem I guess is that when you call ManagedBuildManager.setOption() from within the boolean option valueHandler the string field editor is not called to update the changed string value. It looks like a tricky thing to implement, because changing the actual value of an option could again have sideeffects on enablement/values of other options. You would have to recursively go through all field editors on a page until you are sure no more changes occur. Plus you would have to check for possible infinite recursion, e.g. boolean option 1 switches on boolean option 2 which switches off option 1 which again switches off option 2, etc...
You can't have a target milestone set if no one has taken ownership of the bug to commit to the milestone.
(In reply to comment #2) > Could you please provide any scenario to reproduce a problem ? > > I cannot imagine any situation when widget value is changed > from outside _when_the_widget_is_visible_and_active_. I've got a case which I can't find a workaround for... I have a Toolchain enumeration option for setting chip type which is needed by certain tools. So for the tools themselves I have an hidden enumeration type for which I update the Option value based on the toolchain option's Value. It appears that the optionValue is being correctly updated by the IManagedOptionValueHandler.handleValue() callback, but the Option's value is later reset again during the dialog Apply (as the dialog's hidden list box hasn't updated...) Is it possible to programmatically set a Tool's option based on another Option? If so I haven't figured out how to make it work...
