Select: Fire ValueChange event after using setContainerDataSource

Hello,

is there any way to fire a ValueChange event on a select after the underlying ContainerDataSource gets changed? I need this to build a kind of master->detail->subdetail select where each level is a separate Select whose contents has to get changed when the previous Select changes value. I tried using select(1) to automatically select the first entry, but this only fires a ValueChange when any other value but the first was selected before…

Best regards
Andreas

Which version are you using? Since 6.4 the value of a select is cleared (setValue(null)) in setContainerDatasource method.

cheers,
matti

Hello Matti,

we are “still” using 6.3.4 :wink: You guys just move to fast with new versions which can be quite a problem with production environments :slight_smile:

I will need to check on my development system if 6.4.0 will solve my problem.

Will this also work if I have prevíously called setNullSelectionAllowed(false) on the Select?

Regards
Andreas

Hello Matti,

the new call to setValue(null) after changing datasource seems to kind of resolve my problem. So instead upgrading to 6.4.0 right now, I have added this call right after setContainerDataSource in my code.

IMO there is some ugly catches with this solution:
First, I think that setValue(null) should not be allowed and should in fact raise an Exception, when setNullSelectionAllowed(false) is in operation.
Secondly, I now have to process two ValueChange events, one for the null-selection and the second for my real selection (I have to do a select(1) to reset the displayed item to first one in the new resultset)
Third, I now have to check in the Listener for a selection of null value which formerly was not possible to occur here.

I think it would be cleaner to check whether an item was selected when calling setContainerDataSource and only then fireing a ValueChange event, as data “behind” the selection really has changed.

Best regards
Andreas

Good to hear that it worked.

Null selections are quite problematic and controversy area. I can guarantee that we have thought them a lot. The nullselectionallowed flag controls only the selection by the user. So programmatically the value can still become null even though “nullselection” is not allowed.

cheers,
matti

I can see your pain here. And there sure have been some regressions in 6.4.0. I guess this is a universal problem for all .0 releases :slight_smile: The fix for this issue was so a possibly breaking change in some applications, so we didn’t want to fix it for 6.3 series.

When we get to .1 or .2 I’m sure you want to upgrade.

cheers,
matti