[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).

[claudiobosticco]

Thanks for the detailed explanation. That makes sense now.

With the suggested settings (setting the first column width and/or removing width:"*" from the FileItem), everything works perfectly on my side.

Much appreciated!

[claudiobosticco]

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

Hi, I’m encountering an issue that seems similar to the previous one, but this time with the TextArea.
I’d like to know whether there is a possible workaround here as well, or if this is a bug or something that would require a further enhancement.

With the following example, you can see that the alignment of the right edge of the TextArea (and of the form items in both forms) depends on the width at which the form is rendered:

isc.DynamicForm.create({
    ID: "form1",
    width: "100%",
    border: "1px solid blue",
    numCols: 7,
    colWidths: [200, "*", "*", "*", "*", "*", "*"],
    fields: [
        {name: "foo0", rowSpan: 2, colSpan: 1, showTitle: false, type: "textArea", height: "*"},
        {name: "foo1", endRow: false}, {name: "foo2", endRow: false}, {name: "foo3"},
        {name: "foo4", endRow: false}, {name: "foo5", endRow: false}, {name: "foo6"}
    ]
});
isc.DynamicForm.create({
    ID: "form2",
    width: "100%",
    border: "1px solid blue",
    numCols: 7,
    colWidths: [200, "*", "*", "*", "*", "*", "*"],
    fields: [
        {name: "foo0", rowSpan: 4, colSpan: 1, showTitle: false, type: "textArea", height: "*"},
        {name: "foo1", endRow: false}, {name: "foo2", endRow: false}, {name: "foo3"},
        {name: "foo4", type: "textArea", colSpan: 5, width:"*"},
        {name: "foo5", endRow: false}, {name: "foo6", endRow: false}, {name: "foo7"}
    ]
});

isc.VLayout.create({
    width: "100%",
    border: "1px solid red",
    members: [form1, form2]
})

For example, when the VLayout is 1177 pixels wide, the TextArea is narrower than the available space:



When the VLayout is 1593 pixels wide, the TextArea appears to cause the form to overflow:



In both cases, there are misalignments between the form items of the two forms (for example between form1.foo1 and form2.foo1).

[Isomorphic]

This is another instance of unfulfillable settings.

In Shiva, the default width of TextAreaItem and TextItem is 220, and then there's the default 4px padding (2px per side)

At say 1100px, your colWidths settings mean the first column is 24px too small, so that's why the width of the TextAreaItem ends up 24px too small.

North of 1544 px (200 + 6*224), the problem flips because now the "*" columns are being sized large enough for the content you put in them, so now the TextArea is being sized correctly for the columns it spans. But column 0 is still overflowing by 24px, so the overall form has to overflow.

The new 15.0 autoDetectColumnWidths would have compensated for the bad settings for the "*" columns, but you would still have a problem because you explicitly specified column 0 as too small, and autoDetectColumnWidths only helps with columns with flexible widths.

So, we know this is a toy example, but it can be fixed by just leaving enough space for the items you place in the columns, and with this configuration, there's not really a way to work around this in the framework.

[Isomorphic]

Just a further note here: we don't actually see the overflow at 1544px+. What should be happening is that the browser's table layout algo compensates for you, and reduces the second column (which just has short text - not very wide) and that's what we see.

With fixedColWidths:true, overflow would happen at that size, necessarily, because columns can't shrink. But a normal browser would just reduce the second column to avoid that.

Also, for 15.0, we plan to add some warnings so that if autoDetectColumnWidths is on and you do what you did with column 0 (fixed px width and it's too small) we'll warn about it.