No announcement yet.
  • Filter
  • Time
Clear All
new posts

    SelectItem setPickListProperties with custom ListGrid

    I am currently struggling to get a pick list to be shown with the appearance I want it to.

    What I am doing:
    a) define new class in load_skin.js
    isc.defineClass("MyListGrid", "ListGrid");
    if (isc.MyListGrid) {
          headerHeight: 50,
          headerBarStyle: "dummyStyle",
    b) on the SelectItem
    SelectItem filteredSelect = new SelectItem("a");
    public ListGrid getPL() {
       ListGrid grid = new ListGrid();
       return grid;
    I would expect that the style applied to the header bar and titles would be the one defined in the load_skin.js, but it seems this is not true.

    I have attached a showcase file modified to depict the problem. Unfortunately I could not upload the load_skin.js file due to file size restriction. But the code shown above in a) can be copied/pasted to the showcase load_skin.js file.

    Can you shed some lights on what I am doing wrong?

    smartgwt power 3.1p.2013-11-01
    SmartClient Version: v8.3p_2013-11-01/PowerEdition Deployment (built 2013-11-01)
    Attached Files

    setPickListProperties() is only going to work with a ListGrid object where you've set properties *in Java*.

    It's not clear what you're up to, and this is an odd mix of trying to drive things from JavaScript but still getting Java involved, which seems the worst of the available options..

    To avoid the need to use Java here at all, just use changeDefaults() to configure the PickList purely from JavaScript in load_skin.js.

    To avoid the need to use JavaScript at all, just use setPickListProperties with a ListGrid object where you have set properties in Java.



      Let's say I want to use the approach to avoid the use of Java, but I want a different look & feel for my pick list grid.

      I.e. I use the default ListGrid look and feel for sowing data from a search page for example, but for the picklistgrid of a SelectItem inside my DynamicForm I want a different look and feel. How would I go about it?



        You could define a subclass of SelectItem in load_skin.js and use FormItem.setAttribute("editorType", scClassName) to cause it to be used.

        Here you are intentionally bypassing FormItem.setEditorType(String), which would interpret the String as a Java class instead of a SmartClient class.

        This is a bit of a hack, but then you seem to be looking for a hack, since this is very odd usage.


          We have hit a problem when using the picklist with filter editor enabled and multiple selection option on.

          To reproduce:

          1) filter by some SKU or Item
          2) make selection on any of the rows shown
          3) make new filter by some other SKU or Item (make it so that the item selected on 2) is not shown by the current filter)
          4) make selection of on any of the rows shown

          The selection done on 2) is lost.

          This happens only if the filter used filters the existing selection. If the existing selection is shown by the second filter, then both selections are kept.

          Please see attached modified showcase file.
          Attached Files


            This limitation is actually known, and makes the configuration you have here (a filterable SelectItem pickList coupled with multi-selection) essentially unsupported.
            The problem is that, for a multiple:true SelectItem, there has to be a way to both select and deselect the values.
            If a selected value isn't present in the pickList as an option, and the user selects a new value, if we left the old selection intact in addition to the new selection, the user would have no way to deselect the old value.
            Of course, in your particular case, he could simply clear his filter criteria and the old value would be present in the newly visible records, but we have no way of knowing whether this is the case preemptively.

            We do however support filtering + multi selection via the comboBoxItem (as demonstrated here), so we'd recommend you consider that as a preferable UI.

            Isomorphic Software


              "...but we have no way of knowing whether this is the case preemptively."

              you do: the filter is set on that particular item.

              if the user does not want to clear the filter to deselect previously selected options, then it is the user that is not using the component correctly. The same way he uses the filter to narrow down the options for selection, he should as well use it to deselect previously selected options.

              the option you provide is no option at all as it will have a significant negative impact on the UI.


                "...but we have no way of knowing whether this is the case preemptively."

                you do: the filter is set on that particular item.
                What we know is that there are some criteria applied, and that the current selected value doesn't match any of the options in the pickList.
                Unfortunately, this isn't enough to make the assertion that the user will ever be able to get at the option in the pickList:
                - Firstly, SelectItems frequently have filter-criteria specified for their pickLists which the user never sees. It is very common to filter the list of available options, and not show a filterEditor. Therefore the fact that the data is filtered doesn't necessarily mean that the user can remove that filter. Even if a filterEditor is visible, it may be filtered by a hidden field, etc.
                - Secondly, even if we knew that there is a user-modifiable filter applied to the set of options, we don't know if removing the current criteria would reveal the selected option or not, unless we were tracking both the currently visible data and the superset of unfiltered data which could potentially show (which isn't really viable).

                This is an issue which has been discussed at some length internally.
                If we were to truly add support for this, our likely approach would be to modify the SelectItem UI to display all selected options in a different part of the PickList, so they are always visible, regardless of the current filter criteria, or similar. However adding this as a feature is a non-trivial change, and has not been seen as a priority, as we already have the alternative UI based on a ComboBoxItem with multiple:true and addUnknownValues:false set, as in the example we linked to previously.

                If supporting this feature is a priority for you, we could probably prioritize this work as a feature-sponsorship. If you'd like us to put together an estimate for that, please let us know and we can discuss it further offline.

                However before we go down that route - can you also clarify whether there's something specific about the MultiComboBoxItem which makes it undesirable for your usage? It would seem like this component might just be a better fit for you, so we'd be interested in knowing if there's something specific which is lacking for you.

                Isomorphic Software