Ist da eigentlich die Ausgangsfrage richtig gestellt?
Das Formular an ein StringGrid anpassen ist ja eine Kleinigkeit (ClientWith auf StrigGrid.Width oder Form.AutoSize wurde ja schon genannt).
Nur beides ist natürlich wenig hilfreich, bei den tatsächlichen Wünschen des TS, wie schon festgestellt wurde. Bei AutoSize passt sich das Formular an die StringGrid-Breite an, egal wie sinnvoll die aktuelle StringGrid-Breite eingestellt ist. Gleiches natürlich bei manuellem setzen von ClientWidth.
Die Frage lautet also...
Wie ermittele ich die optimale Breite/Höhe eines StringGrid, damit die Spalten und Zeilen optimal (ohne Scrollbalken und ohne Leerräume) angezeigt werden?
Die Frage nach der Client Breite/Höhe des Formulars ist also völlig unnötig, den die ist nach Klärung der tatsächlichen Frage beantwortet.
***
Eine mögliche Funktion müsste also etwa so aussehen, wie
blauweiss schon im Ansatz gezeigt hat:
Delphi-Quellcode:
function BestStringGridSize(aStringGrid : TStringGrid): TSize;
var
i : Integer;
begin
with aStringGrid do
begin
Result.cx := 0;
for i := 0 to ColCount -1 do
inc(Result.cx, ColWidths[i]);
inc(Result.cx, (GridLineWidth * (ColCount -1)));
Result.cy := 0;
for i := 0 to RowCount -1 do
inc(Result.cy, RowHeights[i]);
inc(Result.cy, (GridLineWidth * (RowCount -1)));
end;
// Add default Bevel Border
inc(Result.cx, 4);
inc(Result.cy, 4);
end;
Mit Size.cx/cy wird dann einfach ClientWidth/ClientHeight des Formulars gesetzt, für eine momentane Anpassung des Formulars oder Form.AutoSize für eine permanente.
Wenn das StringGrid nicht optimal passt (also ohne Scrollbalken und ohne Leerraum), war die Berechnung zu ungenau und muss optimiert werden. Ich denke also auch, das der Ansatz von
blauweiss der richtige ist.
Problem könnten Unterschiedliche Designs von XP/VISTA/Win7 werden... auf ein BevelKind-Stil sollte dann verzichtet werden, um es nicht noch schwerer zu machen.