SelectItem.setAddUnknownValues(false) not working as expected for databound form.

[stonebranch3]

Isomorphic,

We recently upgraded to v12.0p_2018-08-28/Pro Deployment (built 2018-08-28) and unknown values are now showing up in the picklist for SelectItems. This appears to only affect SelectItems if the form has a DataSource.

Please see the following stand-alone test case.

public class UnknownValuesTest extends HLayout implements EntryPoint {

    @Override
    public void onModuleLoad() {
        setLayoutMargin(10);
        setMembersMargin(10);

        DynamicForm localForm = getForm(null);
        localForm.setGroupTitle("Local Form");
        addMember(localForm);

        DynamicForm databoundForm = getForm(getTestDataSource());
        databoundForm.setGroupTitle("Databound Form");
        addMember(databoundForm);

        draw();
    }

    private static DynamicForm getForm(DataSource ds) {
        DynamicForm form = new DynamicForm();
        form.setWidth(300);
        form.setHeight(50);
        form.setIsGroup(true);
        if (ds != null) {
            form.setDataSource(ds);
        }

        SelectItem colorItem = new SelectItem("color", "Color");
        colorItem.setValueMap("Red", "Blue", "Green");
        colorItem.setAddUnknownValues(Boolean.FALSE);

        form.setItems(colorItem);
        form.setValue("color", "Orange");
        return form;
    }

    private static DataSource getTestDataSource() {
        DataSource ds = new DataSource();
        ds.setClientOnly(Boolean.TRUE);

        DataSourceTextField colorField = new DataSourceTextField("color");
        ds.setFields(colorField);

        return ds;
    }
}

The following screenshots illustrate how the SelectItem on the Local Form does not show the unknown value "Orange"; however, the SelectItem on the Databound form does.



Thanks

[Isomorphic]

Can you confirm the version/build you updated from? Is it about a year old, or a bit more?

[stonebranch3]

We upgraded from the following:

SmartClient Version: v10.1p_2017-08-10/Pro Deployment (built 2017-08-10)

Thanks

[Isomorphic]

That explains the apparent regression - a fix was made a year ago to 11.1 and later versions, which was to consider implicit optionDataSources (ie, from a databound parent-form), as well as explicit ones, in certain logic paths associated with client picklist data.

We made a change yesterday which should address this for you - we may end up changing the internal implementation of this fix, but it will remain fixed - you can retest with today's build from smartclient.com/builds.

[stonebranch3]

I've applied today's build and the unknown value no longer shows up in the picklist which is good; however, the value for the SelectItem does not get cleared.

I'm using something similar to the following showcase sample. When the Division is changed, the Department field is cleared if the value is no longer in the new value map; however, it is left behind if the form has a datasource.

https://www.smartclient.com/smartgwt...bobox_category

Thanks.

[Isomorphic]

That's actually documented behavior - please see the doc for addUnknownValues

[stonebranch3]

Just to clarify, my SelectItem does not have an optionDataSource. Only the parent form has a DataSource specified. In this case, the value is not rejected as documented. You can see this behavior with the screenshots for stand-alone test case I provided. The Color field for the Local Form does not display the unknown value "Orange", but it does display it for the Color field for the Databound Form. With today's build, "Orange" is no longer in the picklist, but it is still displayed in the Color field text box.

Thanks

[Isomorphic]

Yes - that's covered by this excerpt: "Note that this property has no effect if the selectItem has a specified optionDataSource. If setValue() is called on a databound SelectItem and the new value does not match any loaded options, the value will be accepted, but not added to the options displayed in the pickList."

That explains the behavior but, we agree, raises the issue of whether this is actually the right behavior, and in particular for implicit optionDataSources.

Leave it with us and we'll get back to you shortly.

[stonebranch3]

I agree that the behavior would be correct for databound SelectItem, but in my case the SelectItem it is not databound--it uses a value map not an optionDataSource. Do you consider it databound because its parent form has a DataSource?

Prior to the upgrade, the value would be rejected in this case so this behavior has changed.

Thanks

[Isomorphic]

Yes, exactly that, and it's the result of the change we made to 11.1+ last summer - that change essentially considers that there's an ODS if the item has an explicit optionDataSource, *or the item represents a field in the parent form's DS* - in the latter case, that's considered an implicit ODS.

Since the item has no explicit ODS, but does have an explicit valueMap, that's what should be being used.

We'll dig into it and get back to you shortly.

[stonebranch3]

OK, that's clear to me now.

Thanks.

[Isomorphic]

We just made a change to address this - please retest with a build dated September 12 or later.

[stonebranch3]

Works great. Thanks!