ListGrid Filter Editor Type overrides the field's editor type in latest 5.1d builds

[mazzi]

In the latest builds of 5.1d (04/27), I started seeing this behavior in ListGrids where if I set a grid's field editor type to say, a SelectItem, and then set the filter editor type of same field to say a TextItem, then when I double click on the field to edit it the editor that comes up is a TextItem rather than the expected SelectItem. This used to work in earlier builds of 5.1d (i.e. you can have different types for a grid field editor/filter editor.
Below is standalone test case using a simplified version of the Showcase's Dependent Selects sample, that reproduces this problem.

Please let me know if you need more info.

Thanks very much for your time.

public void onModuleLoad() {
        VLayout layout = new VLayout(15);

        final ListGrid localDataGrid = new ListGrid();
        localDataGrid.setWidth(500);
        localDataGrid.setHeight(200);
        localDataGrid.setCanEdit(true);
        localDataGrid.setShowFilterEditor(true);
        localDataGrid.setData(EmployeeData.getRecords());

        ListGridField employeeField = new ListGridField("employee", "Name");
        employeeField.setCanEdit(false);

        ListGridField divisionField = new ListGridField("division", "Division");
        SelectItem divisionSelectItem = new SelectItem();
        divisionSelectItem.setValueMap("Marketing", "Sales", "Services");
        divisionSelectItem.addChangedHandler(new ChangedHandler() {
            public void onChanged(ChangedEvent event) {
                //calling 'setValueMap()' will force the 'getEditorValueMap' method to be re-evaluated for the department field
                localDataGrid.setValueMap("department", new LinkedHashMap());
            }
        });
        divisionField.setFilterEditorProperties(new TextItem()); // Setting the filter editor type to something other than the field editor type overrides the type of the field editor
        divisionField.setEditorType(divisionSelectItem);   

        ListGridField departmentField = new ListGridField("department", "Department");

        final Map<String, String[]> departments = new HashMap<String, String[]>();
        departments.put("Marketing", new String[]{"Advertising", "Community Relations"});
        departments.put("Sales", new String[]{"Channed Sales", "Direct Sales"});
        departments.put("Manufacturing", new String[]{"Design", "Development", "QA"});
        departments.put("Services", new String[]{"Support", "Consulting"});

        SelectItem departmentSelectItem = new SelectItem();
        departmentSelectItem.setAddUnknownValues(false);
        departmentField.setEditorValueMapFunction(new EditorValueMapFunction() {
            public Map getEditorValueMap(Map values, ListGridField field, ListGrid grid) {
                String division = (String) values.get("division");
                String[] divisions = departments.get(division);

                //convert divisions into ValueMap. In this case we simply create a Map with same key -> value since
                //stored value is the same as user displayable value
                Map<String, String> valueMap = new HashMap<String, String>();
                for (int i = 0; i < divisions.length; i++) {
                    String val = divisions[i];
                    valueMap.put(val, val);
                }
                return valueMap;
            }
        });
        departmentField.setEditorType(departmentSelectItem);

        localDataGrid.setFields(employeeField, divisionField, departmentField);

        layout.addMember(localDataGrid);

        layout.draw();
    }

[Isomorphic]

This was a regression that occurred around March 23rd that we just fixed late yesterday. The fix will be in the nightly builds of SC 10.1d/SGWT 5.1d dated 5-1-2015.

Please note that the development branch will typically be subject to more such instabilities than release branches such as 5.0p.

[mazzi]

The 5-1-2015 build seems to have fixed the issue. Thanks very much for the prompt response and quick turn around.

On a separate note, the classic devmode debugger issue I have reported in another thread is still there. I have also provided a test case for reproducing it. Any update on that one?

Thanks again,
Mike