ToolStrip width with autoFitColumns

[claudiobosticco]

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

Hi, In a grid I'm using autoFit as shown in the autofitColumns example, but I've also added a ToolStrip to the gridComponents:

isc.ListGrid.create({
    ID: "countryList",
    height:224, width:100,
    data: countryData,
    gridComponents: [
        isc.ToolStrip.create({
            ID: "strip",
            width: "*",
            members: [
                isc.ToolStripButton.create({title: "one"}),
                "starSpacer",
                isc.ToolStripButton.create({title: "two"})
            ]
        }),
        "header", "body"
    ],
    fields:[
        {name:"countryCode", title:"Flag", width:65, type:"image", imageURLPrefix:"flags/24/", imageURLSuffix:".png"},
        {name:"countryName", title:"Country", width:100},
        {name:"capital", title:"Capital", width:100},
        {name:"continent", title:"Continent", width:100}
    ],
    autoFitData: "horizontal",
    autoFitMaxWidth: "100%"
})

However, I can't get the ToolStrip to take up all the available width:



Is there a way to achieve this?

Also, while looking for a possible workaround (for example by observing resized() on the grid), I noticed that if I do:

strip.setWidth(countryList.getViewportWidth());

the grid becomes wider than the grid body itself:

[Isomorphic]

The ToolStrip you added is sizing to the configured width of the overall ListGrid. When you use auto-fitting to have the grid's body adapt to the data, that doesn't auto-apply to other, custom components you've added, because there are dangers there - subtle errors in your sizing approach could lead to infinite layout loops, as two components keep trying to adjust to each other's attempt to auto-size.

In this case, you would just observe the ListGrid or it's body and cause the ToolStrip to match size - that's safe enough in the use case you've shown here. Just be sure to take into account the borders and padding on the various elements, because your ToolStrip is a child of the ListGrid as a whole, and if you size it too large and it expands the ListGrid as a whole, you are into infinite feedback loop territory.

[claudiobosticco]

Hi, thanks for the response.

However, as I mentioned in the original post, when attempting to resize the ToolStrip I noticed that calling strip.setWidth() - regardless of the width value used - causes the grid to gain extra space on the right, as shown in the second screenshot of the original post.

Is this expected behavior, or is it a bug?

[Isomorphic]

This is going to be timing-dependent. With horizontal autofitting, we can't know the width of the grid until the data has been loaded and drawn. So, we don't know when you attempted that call, but the right timing is probably: data has been fetched, the grid body is drawn and has widened relative to the original specified width, and the system has quiesced (AutoTest.waitForSystemDone()).

The other complexity here is, as we mentioned above, border and padding.

It's important to understand exactly what the specified width is vs the viewport width (with an without a scrollbar present) vs the scrollWidth, and how border and padding figure into each. In particular, it looks like the (unknown) timing of your call has introduced an extra scrollbar width, probably by not taking it into account and adding two numbers that both take account of the scrollbar. But what would be correct is, again, timing-dependent.

Basically you are diving into an inherently super-complex asynchronous data-dependent layout problem, adding another element into a layout calculation you don't fully understand...

We're not sure if it's critical for UE to place those controls exactly where you show them, but what you might want to do instead here is just create some space above the grid header (could be canvas.extraSpace or CSS-based) and just use snapTo positioning to put the controls at the left and right edge.

[claudiobosticco]

Hi, sorry, I forgot to mention that I executed strip.setWidth() manually from the browser console, so well after the grid had finished rendering.
That's why it looked like a bug to me.

I was testing again just now and realized that this only happens when the custom scrollbars are visible, as shown in the screenshots (*).

Test case used in the video:

isc.ListGrid.create({
    ID: "countryList",
    height:224, width:100,
    data: countryData,
    gridComponents: [
        isc.ToolStrip.create({
            ID: "strip",
            width: "*",
            members: [
                isc.ToolStripButton.create({title: "one"}),
                "starSpacer",
                isc.ToolStripButton.create({title: "two"})
            ]
        }),
        "header", "body"
    ],
    alwaysShowScrollbars:false,
    fields:[
        {name:"countryCode", title:"Flag", width:65, type:"image", imageURLPrefix:"flags/24/", imageURLSuffix:".png"},
        {name:"countryName", title:"Country", width:100},
        {name:"capital", title:"Capital", width:100},
        {name:"continent", title:"Continent", width:100}
    ],
    autoFitData: "horizontal",
    autoFitMaxWidth: "100%"
})

Code executed from the console:

strip.resizeTo(countryList.getViewportWidth());

(*) Note that I still experience the behavior described here:
https://forums.smartclient.com/forum...161#post273161

Also, I now have a different Mac than the one I had when I wrote that post.

[Isomorphic]

That timing sounds like it would be fine, but you still need to understand the various widths and what they mean. You will also need to figure out how to respond when the grid changes size due to data changes (as an example). So it gets pretty complex - more in the realm of a Feature Sponsorship if you want help here, because you're trying to get involved in a very complex internal auto-sizing calculation, finding out the necessary value at the perfect moment, and avoiding the possibility of infinitely looping layout.

If you don't want to dig into that, it's probably best to use the simplified strategy we recommended above, in which case, you don't need to deal with any of that complexity - it's very simple.

[claudiobosticco]

Ok, thanks. I used an approach similar to the one you suggested.