Stringgrid resize

[sfein1000]

Setup:
Linux - Debian Pixie with KDE desktop and Wayland
FPC: 3.2.2 installed using fpcupdeluxe
FPGui: 2.1.0 - compiled with unix

I am working on an app where I would like to resize the columns of a stringgrid whenever the grid resizes (which would occur when the form resizes). I am using MigLayout. Code looks like:
mig.AddLayoutComponent(gridResults, TfpgMigCC.Create.SpanX(4).GrowX.GrowY.PushY)

I looked for an OnResize for stringgrid and did not see one. I then tried OnResize for the form. That gets called but the Width of the form and for the grid (I tried both) acted like there was no change. What I ended up doing was overriding the HandleResize method of the form (since a width is passed into that method). This works fine, but seems like I am doing this wrong. Is there a better way?

Thanks,
Steve

[graemeg]

Thanks for the clear write-up — and apologies for the slow reply. The HandleResize override you landed on is actually the idiomatic fpGUI pattern, so you weren't doing anything improper. But you hit two genuine papercuts, and one of them is squarely our fault.

1. OnResize was missing from the grid — now fixed

The event has always existed on TfpgWidget, and the notification path fires correctly, including when a layout manager resizes a widget. It simply was never republished on the grid classes, so it was invisible to user code and to the designer. That was an oversight on our side. TfpgStringGrid and TfpgFileGrid now publish OnResize in the develop branch.

2. Width in fpGUI is not what it is in Lazarus/LCL

This is why your handler saw "no change", and it trips up nearly everyone arriving from FPC/Lazarus. It's worth explaining properly, because it's a deliberate design decision rather than a bug.

In the LCL, Width is a single value: you set it, and that's also what gets rendered. fpGUI splits that into two:

• Width / Height — the intent size. The size you asked for. Setting it expresses a preference.
• ActualWidth / ActualHeight — the actual size. What the widget currently occupies on screen after layout has run.

Width returns the preferred size, so on a widget managed by MigLayout it keeps reporting the size you originally requested while the widget visibly grows and shrinks. That's exactly the behaviour you observed. Your HandleResize override worked because the real size arrives as a parameter, sidestepping the property entirely.

Why it works this way: layout managers drove the split. Once a layout manager owns a widget's geometry, "the size the developer wants" and "the size the widget actually got" stop being the same number — the manager grants space based on available room, size constraints, and the other components competing for it. If both collapse into one property, the manager's assignment overwrites your stated intent, and on the next relayout there's nothing left to reason from. Keeping them separate lets GrowX/GrowY do their job while your requested size survives as the input to the next pass. It's the same intent-vs-actual split WPF uses (Width vs ActualWidth), and for the same reason.

Rule of thumb: reading a size for rendering, hit-testing, or arithmetic → ActualWidth. Setting a size to express what you want → Width.

Putting it together

With OnResize now exposed, no subclassing is needed:

procedure TMainForm.GridResized(Sender: TObject);
var
  fixed, i: integer;
begin
  fixed := 0;
  for i := 0 to gridResults.ColumnCount-2 do
    fixed := fixed + gridResults.ColumnWidth[i];
  gridResults.ColumnWidth[gridResults.ColumnCount-1] :=
      gridResults.ActualWidth - fixed - gridResults.ScrollBarWidth - 4;
end;

Wire it up with gridResults.OnResize := @GridResized;. Treat the trailing constants as illustrative — the exact allowance for grid lines depends on your ShowGrid setting, and subtracting ScrollBarWidth is only correct while the vertical scrollbar is actually visible.

One detail worth knowing: use ColumnWidth[i], not Columns[i].Width. Columns[].Width is a raw field write — it skips the 1px minimum clamp and doesn't refresh the grid, so you end up with a stale scrollbar range and no repaint. ColumnWidth[] does both.

Your HandleResize override remains perfectly valid too, and is the better choice if you're already subclassing — just remember to call inherited and to bail out early when csLoading in ComponentState.

On automatic column sizing

You've highlighted a real gap: there's no AutoSizeColumn or stretch-last-column mode, so this redistribution has to be hand-rolled every time. We're considering a per-column stretch weight, following MigLayout's grow model — weight 0 stays fixed, weights above 0 share the slack proportionally. If you have thoughts on what would suit your use case, they'd be very welcome before we settle on an API.

[sfein1000]

Downloaded and built dev branch.

OnResize works perfectly using ActualWidth - Scrollbar. I don't mind the space without scrollbar so did not write code checking if scrollbar was visible. I was already using CoumnWidt so no change needed from me there. I totally missed the ActualWidth property when looking at code to decide what to use :)

I think I prefer the OnResize to HandleResize, so I'll leave that code.

For my use case on autosize, though I use pascal for my own projects, work was 90% Java (10% C# and VB) and I found that using layout managers, I just could never get what I wanted correctly using weights. I prefer the technique I use in code which is percents. So, if you're looking at my preference, I like OnResize event with me calculating a percent of width for each column without using and autoresize option.

[graemeg]

Manual size calculations and auto-sizing is now possible. :-)

[graemeg]

Quick follow-up: rather than leaving this as "something we're considering", the stretch weights are now implemented and pushed to develop.

Each column gains a Stretch weight. A weight of 0 (the default) keeps the column fixed at its set width; any column with a weight above 0 shares out whatever width is left over, in proportion to its weight. So for your four-column grid, if you wanted the last two columns to share the spare space with the last one getting half as much:

gridResults.ColumnStretch[2] := 2;
gridResults.ColumnStretch[3] := 1;

Columns 0 and 1 keep the widths you set, and 2 and 3 split the remainder 2:1. No OnResize handler and no HandleResize override needed — the grid recalculates on every resize by itself. If you just want the last column to soak up all the slack, a single ColumnStretch[n] := 1 does it.

A few details worth knowing:

• ColumnMinWidth[i] sets the floor a stretch column will not shrink past (8 pixels by default). If the grid gets too narrow to honour every minimum, the columns overflow and the horizontal scrollbar appears as normal.
• Widths always add up exactly to the available width; any rounding remainder goes to the last stretch column, so you won't see a stray gap on the right-hand edge.
• Dragging a column's header divider clears that column's weight, pinning it at the width you dragged to. This seemed the least surprising choice — otherwise your drag would be silently undone on the next resize. Assign a weight again to put the column back to sharing.

Both changes from my earlier reply are on develop now: OnResize is published on TfpgStringGrid and TfpgFileGrid, and the stretch weights come with unit tests plus a worked example in examples/gui/gridtest/.

Thanks for raising this — the missing OnResize was a genuine oversight on our part, and the automatic column sizing had been a gap for a long time. Do give it a try and say if the behaviour doesn't match what you were after.