Announcement

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

    ListGrid.filterEditor and ListGrid.filterEditorProperties are undefined

    Referring to: https://www.smartclient.com/smartcli...ase/?id=filter

    I've modified the code

    Code:
    var grid = isc.ListGrid.create({
        ID: "countryList",
        width:500, height:300, alternateRecordStyles:true,
        dataSource: worldDS,
        fields:[
            {name:"countryCode", title:"Code", width:60},
            {name:"countryName", title:"Country"},
            {name:"capital", title:"Capital"},
            {name:"continent", title:"Continent"}
        ],
        autoFetchData: true,
        showFilterEditor: true   // <-- If showFilterEditor is set to true, the filterEditor is automatically created as an AutoChild.
    });
    
    say("filterEditor=" + grid.filterEditor + "<br/> filterEditorProperties=" + grid.filterEditorProperties);
    When run, it shows that both .filterEditor and .filterEditorProperties are undefined.

    I would like to modify the background color on the filter editor row. Is this the correct approach or is there another way?

    Thanks.







    #2
    Set filterEditorProperties, same pattern as for all other AutoChildren.

    Comment


      #3
      Ok. I guess I misunderstood the documentation. I thought the AutoChild would have already been created whether I set a property or not. I guess it's only created IF I set a property.

      So, with the following code, I can set the background color but it's not what I was expecting. I was expecting the background of all the filter fields to change but only the button color changed.

      Code:
      let grid = isc.ListGrid.create({
          ID: "countryList",
          width:500, height:300, alternateRecordStyles:true,
          dataSource: worldDS,
          fields:[
              {name:"countryCode", title:"Code", width:60},
              {name:"countryName", title:"Country"},
              {name:"capital", title:"Capital"},
              {name:"continent", title:"Continent"}
          ],
          autoFetchData: true,
          showFilterEditor: true,
          filterEditorProperties: {backgroundColor : "blue"}   // Will turn the filter icon blue
      });
      
      grid.filterEditorProperties.backgroundColor = "green";   // Will turn the filter icon green
      How can I change the background color of the individual filter fields?

      Thanks.

      Comment


        #4
        No, whether you set filterEditorProperties does not affect whether the AutoChild is created, it’s based on the showAutoChildName flag, or in some cases, other conditions, as doc’d on the particular AutoChild.

        You successfully set the background color of the AutoChild, but in the case of the ListGrid FilterEditor, you have FormItems of various kinds, one per field, and those are opaque children of the FilterEditor, so it’s background color doesn’t show through.

        You can customize each individual item via field.editorProperties, or provide a subclass via field.editorType. But unless you want to start down the path of creating an alternate look and feel for every FormItem that can appear as a filter item (TextItem, SelectItem, ComboBoxItem, MiniDateRangeItem, etc), we wouldn’t really recommend going down this path.

        Comment


          #5
          Ok, that's what I thought but in my first example, showfilterEditor was set to true during the .create() and yet after the create, the grid.filterEditor is undefined. Shouldn't it have been created in the .create()?

          Regardless, I now know that I can set filterEditorProperties to something and it'll work, whether or not it is created during the create.

          No, I don't want to create an alternate look and feel for every FormItem that can appear as a filter item. I am just applying a slight highlight to certain fields to let the user know that they should put a value in one of the fields before data is fetched. I've got it working the way I intended now with the following code:

          Code:
          /* CSS File */
          .requiredFilterField {
              background-color: lightyellow !important;  /* !important to override the textItemLite background color */
          }
          
          /* TypeScript */
          // this.arrRequiredFields is an array of field names that are required in the filter row in order to initiate a fetch
          $.each(this.arrRequiredFields, (index: number, value: string) => {
          
              let field: Isc.ListGridField = grid.getField(value);
          
              if (field) {
                  // Merge the existing properties with more properties, last wins
                  field.filterEditorProperties = {
                      ...field.filterEditorProperties,
                      ...{
                           /* This is the key, textBoxStyle really means CSS class(es). Be sure to include the original textItemLite class
                            * or else the borders will look weird. textBoxStyle handles textboxes and dropdowns which is all that I need.
                            * If you have other types of FormItems in the filter row, other properties might be required.
                            */                                                          
                          "textBoxStyle": "requiredFilterField textItemLite"     
                         }
                  };                            
              }
          });
          Thanks.

          Comment


            #6
            AutoChildren are usually created on draw, unless needed sooner.

            Note that directly accessing the created AutoChild should pretty much be a last resort; as the docs warn, the AutoChild system gives you a lot of power, but you need to be careful to not rely on undocumented behavior.

            Your current approach, however, is fine.

            Comment


              #7
              "textBoxStyle": "requiredFilterField textItemLite"
              Hi Isomorphic , just a quick question: is this officially supported, I mean multiple css classes for a *style attribute?

              Comment


                #8
                Oh, we didn’t notice that. No, that is not a supported approach, and can cause sizing errors because we need to go look at the CSS style definitions in order to plan how big to render controls, And we expect a single style name.

                Comment


                  #9

                  1. Re:
                  AutoChildren are usually created on draw, unless needed sooner.
                  Can that be included in the documentation? The docs for AutoChild don't mention anything about OnDraw and I never would have figured that out myself.

                  2. If setting multiple classes is not supported, what would be the more appropriate approach be to achieve my goal here?

                  Comment


                    #10
                    1. sure, we'll add something, although to clarify, that's not a very general rule - there are multi-autoChildren and non-widget autoChildren, etc. And again, don't access the live pointer unless you have a very very good reason - you are really asking for forward compatibility issues by doing so

                    2. just combine the settings into a single CSS class or class series

                    Comment


                      #11
                      We've updated the docs for AutoChildren to clarify the point #1 and they should be available as of tomorrow's builds.

                      Note that AutoChildren are not always created as soon as the parent component, and may be created only when the parent is drawn, or in some cases, only when needed. For the best chance of forward compatibility, use properties and defaults instead of accessing the live reference, and if you do access the live reference, access it only when it is clear that the AutoChild must have been created by that point. For example, even if you determined by experimentation that the Window class currently creates it's "header" AutoChild when the Window is created, you should avoid accessing it until the Window has drawn, to leave room for the Window's implementation to change such that creation of the "header" AutoChild is deferred until draw.
                      Regards
                      Isomorphic Software

                      Comment

                      Working...
                      X