[claudiobosticco]

SmartClient Version: v13.1p_2026-01-09/AllModules Development Only (built 2026-01-09)

Hi, the behavior has improved, but I still see the issue within a narrower range of visible widths.
Basically, at around 990px or less of visible width, the alignment is perfect:



When I widen the layout, some misalignment starts to appear:



and initially increases, but as I keep widening it, the misalignment starts to decrease again, eventually returning to perfect alignment at around 1289px or more:



This is with Chrome and Firefox on macOS. With Safari, the range with misalignment is wider and extends to almost 1500px in width.

[Isomorphic]

Having fixed the framework bug where room wasn't properly left for the hint on FileItem/CanvasItem, the remaining problem is an issue in your application code (although a further framework enhancement could work around it..).

Basically:

1) colWidths all *s means "split space equally"

2) the textArea in the first column has a default fixed width of 250

3) at various widths, the equal split gives each column ~110px - less than the textarea needs.

For the first form (no FileItem), the browser's automatic table layout heuristics compensate for the content in col 0 being larger than the specified size by shrinking the title columns to compensate.

For the second form (has FileItem), the FileItem spans several columns, and writes out content that fills the space allocated to those columns. So the browser's table layout heuristics can't shrink those columns, hence overflow.

You can fix this by:

1) setting the colWidth for the first column large enough to accommodate your TextArea (e.g. 160)

2) not setting width:"*" on the FileItem. In general for a FileItem (or CanvasItem), if you set width *, you are basically forcing fixedColumnWidths for whatever columns the CanvasItem occupies - the browser won't shrink those columns to fit content anymore

We could also fix this in the framework with a new rule: if you set colWidths:"*" but there's a fixed-sized item in the column, treat that as a minimum when calculating column widths. Let us know if you'd like to pursue Feature Sponsorship for this; otherwise, it just goes into the queue and may not happen for a long while.

[Isomorphic]

As far as the feature, actually, we just went ahead and did it (things move much faster with AI). It's only for 15.0, however.

With the new version, your original test case now works despite the colWidths being technically incorrect (not enough space for certain items).