Announcement

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

    Question about autoFit behavior in grids during editing

    SmartClient Version: v13.1p_2025-07-24/AllModules Development Only (built 2025-07-24)

    Hi, I have a question about autoFit in grids. Using the test case below, I noticed that when I edit a record, the auto-fit width seems to consider the space needed for editing, at least for the date field:

    Click image for larger version

Name:	2025-07-25 10.43.53.jpg
Views:	78
Size:	18.6 KB
ID:	276105


    If this behavior is actually intended, it's pretty cool. Is it configurable by any chance?

    Also, I see that there isn't a similar behavior for selectItem or numeric values:


    Click image for larger version

Name:	2025-07-25 10.44.00.jpg
Views:	60
Size:	20.9 KB
ID:	276106

    While I must say that for the selectItem this is not really a problem, I was thinking that maybe adding a little extra space, to account for the padding in the textBox, could make editing more comfortable. What do you think?

    Code:
    isc.ListGrid.create({
        ID: "countryList",
        width:550, height:224,
        dataSource: countryDS,
        fields:[
            {autoFit:"both", name:"countryCode", title:"Flag", width:40, type:"image", imageURLPrefix:"flags/24/", imageURLSuffix:".png", canEdit:false},
            {autoFit:"both", name:"countryName"},
            {autoFit:"both", name:"continent"},
            {autoFit:"both", name:"member_g8"},
            {autoFit:"both", name:"population",
                validators:[
                    {type:"integerRange", min:1}
                ]
            },
            {autoFit:"both", name:"independence"}
        ],
        autoFetchData: true,
        canEdit: true,
        editEvent: "click"
    })

    #2
    Although it's an interesting feature idea, no, autofitting does not currently take into account the width of the editor.

    In your sample code, the reason the "independence" field is wider than necessary to show the date values is because you set autoFit:"both", which means take the larger of the data width and the title width. The title is "Independence" so that makes the field wider.

    Comment


      #3
      Originally posted by Isomorphic View Post
      Although it's an interesting feature idea, no, autofitting does not currently take into account the width of the editor.

      In your sample code, the reason the "independence" field is wider than necessary to show the date values is because you set autoFit:"both", which means take the larger of the data width and the title width. The title is "Independence" so that makes the field wider.
      Hi, actually if you try the exact same code but with canEdit:false, you'll see that the field remains narrower, as if it takes the date chooser icon into account.

      Comment


        #4
        SmartClient Version: v14.1p_2026-06-11/AllModules Development Only (built 2026-06-11)
        SmartClient Version: v13.1p_2026-06-08/AllModules Development Only (built 2026-06-08)

        Hi, I wanted to follow up on this thread because, in addition to datetime columns still appearing too wide when using autoFit set to either both or value, I've now noticed that columns with type time seem to allocate an even more excessive amount of space.

        Please try this test case in the databoundTimeline sample:

        Code:
        isc.ListGrid.create({
            ID: "testGrid",
            height: 475,
            canEdit:true,
            dataSource: tasks,
            autoFetchData: true,
            fields:[
                {name: "name", autoFit: "both"},
                {name: "description", autoFit: "both"},
                {name: "startDate", autoFit: "both", title:"start"},
                {name: "endDate", autoFit: "both", title:"end", type:"time", timeFormatter: "toShort24HourTime"},
            ],
            autoFitData: "horizontal",
            autoFitMaxWidth: "100%",
            leaveScrollbarGap: false
        });
        This is Shiva in Spacious density setting:

        Click image for larger version

Name:	2026-06-12 12.13.20.jpg
Views:	0
Size:	25.6 KB
ID:	277587

        Comment


          #5
          hi Claudio,

          What you're seeing is the result of the settings below, which are in the isc.ListGrid block in load_skin.js - these settings are all doc'd and act as minimum widths when autoFitDateFields / autoFitTimeFields is "value" (the default).

          However, there is an internal aspect to this - if you're using Spacious mode, for example, these values are increased by a scale-factor based on the fontIncrease, and that mechanism is undoc'd and may be applying excessive additional width.

          We'll take a look and make a note to review/choose better skin-defaults for these (especially the time one which, mysteriously, is wider then the date one!), but you can change them in your own skin, in the meantime.

          Code:
                      // default Date, Time, and DateTime listGridField widths
                      defaultDateFieldWidth: 65,
                      defaultDateTimeFieldWidth: 104,
                      defaultEditableDateFieldWidth: 114,
                      defaultEditableDateTimeFieldWidth: 150,
                      defaultTimeFieldWidth: 75,
          Last edited by Isomorphic; Today, 05:37.

          Comment


            #6
            Hi, thanks for the detailed explanation and for looking into this.

            Just as an additional data point: I'm seeing what feels like excessive width even when using Dense density mode, not only in Spacious mode:

            Click image for larger version

Name:	2026-06-12 15.50.40.jpg
Views:	0
Size:	25.6 KB
ID:	277595

            Comment


              #7
              Yes - the values are probably just too big in the first place, and they're being scaled as well, perhaps over-zealously!

              You can do isc.ListGrid.addProperties({ defaultDateTimeFieldWidth: 80 }), for example, in the console and reload the sample to confirm you see the changes you expect.

              Comment

              Working...
              X