Mehrere Formulare an Stringgridgröße anpassen

[Delphi-Laie]

Zitat:

Zitat von sx2008 (Beitrag 1058709)

Eine Procedure, Funktion oder Methode sollte genau eine Aufgabe durchführen.

Ist das nicht Ansichtssache?

Letztlich ist auch eine Unit ein Modul, und zwar eines, das meistens Code für ziemlich viel Aufgaben enthält und i.d.R. auch durchführt.

Zitat:

Zitat von sx2008 (Beitrag 1058709)

Falls mehr als eine Aufgabe durchgeführt wird, müssen die Teilaufgaben als Unterfunktionen implementiert werden.

Vermutlich meinst Du, wenn an verschiedenen Codestellen der (prinzipiell) gleiche Code im Quelltext vorhanden ist bzw. beim Programmablauf ausgeführt wird, dann sollten Unterprogramme eingesetzt werden.

Zitat:

Zitat von hoika (Beitrag 1058716)

Delphi-Quellcode:

ColWidths[x] := biggestwidth + 6;

Der Grund für das +6 würde mich mal interessieren.
Ist das die Breite einer Scrollbar ?

Ich kann nur für mich antworten. Ich fummelte mir einen ähnlichen Wert zurecht, damit das Stringgrid nicht gar zu gequetscht wird: So ist wenigstens noch ein ganz klein wenig Platz zwischen Schrift und Spaltentrennern.

Zitat:

Zitat von hoika (Beitrag 1058716)

Der Code funktioniert übrigens wohl auch nicht im FormCreate,
sondern erst im FormActivate (Canvas ist noch nicht richtig initialisiert)

Jein. Bei Delphi 2 und 3 funktioniert er auch schon im FormCreate (ich deutete das weiter vorn an), ab Delphi 4 leider nicht (da habe ich umständlich zwei Codeblöcke, je nachdem, ob Anfang oder später). Aber nunmehr bin ich dank Deiner auf eine Fährte gestoßen, die den Code, was die Delphi-Versionen anbetrifft, evtl. universeller gestalten läßt.

[sx2008]

Zitat:

Zitat von Delphi-Laie (Beitrag 1058748)

Zitat:

Zitat von sx2008 (Beitrag 1058709)

Eine Procedure, Funktion oder Methode sollte genau eine Aufgabe durchführen.

Ist das nicht Ansichtssache?

Eher eine professionelle Einstellung zum Programmieren.
In dem Buch "Clean Code: A Handbook of Agile Software Craftsmanship" von Robert C. Martin wird das ausführlich beschrieben.
Kurzzusammenfassung

[Bummi]

@sx2008
wenn ich die Kurzzusammenfassung lese, kann ich mich den wenigsten Punkten uneingeschränkt anschließen.

[BUG]

Zitat:

Zitat von Bummi (Beitrag 1058841)

@sx2008
wenn ich die Kurzzusammenfassung lese, kann ich mich den wenigsten Punkten uneingeschränkt anschließen.

Du brauchst dich ja nicht dogmatisch an das Buch halten (steht sogar im Buch, nur beim "Durcharbeiten" der darin enthaltenen Übungen soll man sich darauf einlassen).
Und die Kurzzusammenfassung kann die Überzeugungsarbeit des Buches nicht bei weitem leisten, dazu ist sie einfach zu knapp :)

[Delphi-Laie]

Zitat:

Zitat von sx2008 (Beitrag 1058834)

Zitat:

Zitat von Delphi-Laie (Beitrag 1058748)

Zitat:

Zitat von sx2008 (Beitrag 1058709)

Eine Procedure, Funktion oder Methode sollte genau eine Aufgabe durchführen.

Ist das nicht Ansichtssache?

Eher eine professionelle Einstellung zum Programmieren.

Eine Einstellung (und nichts anderes ist es) zum professionellen Programmieren wäre ein klein wenig dezenter gewesen. Eine Einstellung (!) jedoch als "professionell" hinzustellen, halte ich - mit Verlaub - schon ein wenig für überheblich.

Letztlich ist es doch auch (und gerade?) im Bereich der Programmierung, der Informatik, wie übrigens in jeder Wissenschaft, in jedem Fachgebiete, so, daß alle möglichen, teilweise sogar konträre Meinungen aufeinanderprallen - manchmal sogar mehr, als es Diskutanten gibt.

Natürlich kann man Programmaufgaben so weit "herunterbrechen" (schönes Modewort), daß zum Schluß fast nur noch die einzelne Anweisung übrigbleibt. Hinsichtlich der Fehleranfälligkeit, Übersichtlichkeit und Wartbarkeit des Quelltextes, der Größe und Ablaufgeschwindigkeit des Compilates u.ä. Größen mag das aber nicht gerade Optimum sein - und schon gar nicht pauschal.

[Delphi-Laie]

Zitat:

Zitat von blauweiss (Beitrag 1058651)

Hallo,

was macht ihr da, und warum.....?:shock:

Warum nicht einfach so:

Delphi-Quellcode:

function GetGridWidth(aStringGrid: TStringGrid): integer;
var
  i: integer;
begin
  Result := 0;
  with aStringGrid do
    for i := 0 to ColCount-1 do
      inc(Result, ColWidths[i] + GridLineWidth);
end; // GetGridWidth

function GetGridHeight(aStringGrid: TStringGrid): integer;
var
  i: integer;
begin
  Result := 0;
  with aStringGrid do
    for i := 0 to RowCount-1 do
      inc(Result, RowHeights[i] + GridLineWidth);
end; // GetGridHeight

procedure AdjustFormSize(aStringGrid: TStringGrid; aForm: TForm);
begin
  with aStringGrid do
    begin
      ClientWidth := GetGridWidth(aStringGrid);
      ClientHeight := GetGridHeight(aStringGrid);
    end;
  aForm.AutoSize := true;
end; // AdjustFormSize

und dann im FormShow oder wo es passieren soll

Delphi-Quellcode:

procedure TForm1.FormShow(Sender: TObject);
begin
  AdjustFormSize(StringGrid1, Self);
end;

Ganz einfache Antwort: Weil dieser Code nicht so funktioniert, wie ich es wünsche und auch beschrieb. Nicht nur, daß die Scrollbalken zu sehen sind (sofern erlaubt), das StringGrid wird nicht vollständig dargestellt (auch dann nicht, wenn der Bildschirm dafür eigentlich groß genug ist), und das Formular ist "dank" AutoSize nicht einmal mehr manuell zoombar.

Sooo simpel ist es also wohl nicht, womit auch die Frage nach dem Warum beantwortet ist.

[BUG]

Zitat:

Zitat von Delphi-Laie (Beitrag 1058881)

[...]

Sicher kann man es auch übertreiben oder gar missverstehen und ins Gegenteil verkehren.

Aber vielfach ist Programmieren ein Kampf gegen Komplexität.
Man hackt sie in Teile, packt sie in Boxen und wendet abstrakte (und damit einfachere) Konzepte auf sie an, um Probleme zu lösen, die man im Ganzen nicht fassen kann.
Dabei sollte man sich (ohne vernünftigen Grund) nicht selbst in den Rücken fallen.


Warum sind zum Beispiel funktionale Programmiersprachen zur Zeit für viele interessant: Seiteneffektfreiheit.
Das Beschränken einer Funktion/Prozedur auf eine Aufgabe könnte man als schwächeres verwandtes Konzept verstehen. Es kann zwar Seiteneffekte geben, aber diese sollten sich nur auf für Entwickler erwartbare Teile des Programms auswirken.

Zitat:

3.) das Formular unsichtbar und wieder sichtbar machen

Zum Beispiel das ist völlig unerwartet für "Form_Skalieren". Wenn du diese Prozedure eventuell später an anderer Stelle aufrufst, wunderst du dich, warum dein Formular "flackert", onShow ausgeführt wird und dein Formular zentriert wird.
Da bist du den Fehler gefunden hast ...

[Satty67]

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.

[blauweiss]

Hallo Delphi-Laie,

Zitat:

Zitat von Delphi-Laie (Beitrag 1058707)

Die Skalierung des Stringgrids, konkret der Minimierung seiner Spaltenbreiten, ist nicht mein Problem; meine Codezeilen dazu funktionieren. Deine sind m.E. auch nicht substantiell anders; mir scheint sogar so, als daß meine sogar ein Quentchen effizienter sind, da ich die Spaltenbreiten anfangs nicht einnull(t)e (so sah man Code früher auch aus), sondern gleich mit der Spaltenbreite der ersten Zeile bestücke.

Dein Code dazu:

Delphi-Quellcode:

for l:=0 to pred(StringGrid.ColCount) do StringGrid.ColWidths[l]:=Zellenbreitenzuschlag+StringGrid.Canvas.TextWidth(StringGrid.Cells[l,0]); //Skalieren nach Tabellenkopf
for l:=0 to pred(StringGrid.ColCount) do for m:=1 to pred(StringGrid.RowCount) do
  if StringGrid.ColWidths[l]<Zellenbreitenzuschlag+StringGrid.Canvas.TextWidth(StringGrid.Cells[l,m])
  then StringGrid.ColWidths[l]:=Zellenbreitenzuschlag+StringGrid.Canvas.TextWidth(StringGrid.Cells[l,m]);

Mein Vorschlag:

Delphi-Quellcode:

procedure MinimizeColWidths(aStringGrid: TStringGrid);
var
  x, y: integer;
  onewidth, biggestwidth: integer;
begin
  with aStringGrid do
    for x := 0 to ColCount-1 do
      begin
        biggestwidth := 0;
        for y := 0 to RowCount-1 do
          begin
            onewidth := Canvas.TextWidth(Cells[x, y]);
            if (onewidth > biggestwidth) then
              biggestwidth := onewidth;
          end;
        ColWidths[x] := biggestwidth + 6;
      end;
end; // MinimizeColWidths

Dein Code ist nicht effizienter, sondern 1. unleserlich und 2. weniger performant, da bei Dir x-mal die Spaltenbreite eines StringGrids geändert wird, bei mir nur 1-mal.

Zitat:

Zitat von Delphi-Laie (Beitrag 1058707)

Das mit dem Constrain stimmt: Das Fenster ist merkwürdigerweise auf 112 Pixel (das Minimum) voreingestellt, so daß die Dekrementierungsschleife natürlich endlos wird. Merkwürdig, wenn die Codezeilen direkt verwende, funktionieren sie tadellos.... Danke auch für diesen Hinweis!

Ich will Dir nicht zu nahe treten, aber das halte ich für ausgeschlossen.

Zitat:

Zitat von hoika (Beitrag 1058716)

Delphi-Quellcode:

ColWidths[x] := biggestwidth + 6;

Der Grund für das +6 würde mich mal interessieren.
Ist das die Breite einer Scrollbar ?

Dieses +6 hatte ich als Wunsch des OP interpretiert, die Zelleninhalte nicht bündig in die Spalten zu quetschen. Sie tauchen in seinem Code als Konstante auf, die ich mir erspart habe.

Zitat:

Zitat von hoika (Beitrag 1058716)

Ich würde den Code auch mal mit "large fonts" testen.

Sollte in Canvas.TextWidth berücksichtigt werden.

Zitat:

Zitat von hoika (Beitrag 1058716)

Der Code funktioniert übrigens wohl auch nicht im FormCreate,
sondern erst im FormActivate (Canvas ist noch nicht richtig initialisiert)

Deshalb hatte ich auch FormShow vorgeschlagen.

Zitat:

Zitat von Delphi-Laie (Beitrag 1058881)

Zitat:

Zitat von sx2008 (Beitrag 1058834)

Zitat:

Zitat von Delphi-Laie (Beitrag 1058748)

Zitat:

Zitat von sx2008 (Beitrag 1058709)

Eine Procedure, Funktion oder Methode sollte genau eine Aufgabe durchführen.

Ist das nicht Ansichtssache?

Eher eine professionelle Einstellung zum Programmieren.

Eine Einstellung (und nichts anderes ist es) zum professionellen Programmieren wäre ein klein wenig dezenter gewesen. Eine Einstellung (!) jedoch als "professionell" hinzustellen, halte ich - mit Verlaub - schon ein wenig für überheblich.

Letztlich ist es doch auch (und gerade?) im Bereich der Programmierung, der Informatik, wie übrigens in jeder Wissenschaft, in jedem Fachgebiete, so, daß alle möglichen, teilweise sogar konträre Meinungen aufeinanderprallen - manchmal sogar mehr, als es Diskutanten gibt.

Natürlich kann man Programmaufgaben so weit "herunterbrechen" (schönes Modewort), daß zum Schluß fast nur noch die einzelne Anweisung übrigbleibt. Hinsichtlich der Fehleranfälligkeit, Übersichtlichkeit und Wartbarkeit des Quelltextes, der Größe und Ablaufgeschwindigkeit des Compilates u.ä. Größen mag das aber nicht gerade Optimum sein - und schon gar nicht pauschal.

Deine Reaktion auf Foristen, die Dir helfen wollen, ist ungewöhnlich. Die Herangehensweise an Deine Probleme, Deine Problembeschreibungen sowie die Reaktion auf Vorschläge Anderer scheint mir nicht professionell. Das ist nicht überheblich, denn Du wirst wohl nicht professionell (beruflich) programmieren, oder ?

Zitat:

Zitat von Delphi-Laie (Beitrag 1058882)

Ganz einfache Antwort: Weil dieser Code nicht so funktioniert, wie ich es wünsche und auch beschrieb. Nicht nur, daß die Scrollbalken zu sehen sind (sofern erlaubt), das StringGrid wird nicht vollständig dargestellt (auch dann nicht, wenn der Bildschirm dafür eigentlich groß genug ist)

Ich sehe 2 mögliche Knackpunkte:
1. Setzen von ClientWidth und ClientHeight des StringGrid funktioniert nur dann wie gewünscht, wenn StringGrid.ScrollBars = ssNone
2. TForm.AutoSize scheint tatsächlich ein Problem damit zu haben, die Größe des Forms zu vergrößern, um alle Controls darzustellen. Verkleinern funktioniert aber.
Also bietet es sich an, die Form-Größe auf einen hinreichend großen Wert zu setzen und dann AutoSize auf true zu schalten. Siehe auch unten.

Zitat:

Zitat von Delphi-Laie (Beitrag 1058882)

und das Formular ist "dank" AutoSize nicht einmal mehr manuell zoombar

Davon war zuvor nach meiner Erinnerung keine Rede, aber auch hier kann Dir geholfen werden:

Delphi-Quellcode:

aForm.AutoSize := true;
aForm.AutoSize := false;

Grüße,
blauweiss

[Delphi-Laie]

Zitat:

Zitat von blauweiss (Beitrag 1059006)

Dein Code ist nicht effizienter, sondern 1. unleserlich und 2. weniger performant, da bei Dir x-mal die Spaltenbreite eines StringGrids geändert wird, bei mir nur 1-mal.

Zweites ist richtig, wie ich nunmehr einsehe. Ich werde die Spaltenbreitenanpassung des Stringgrids diesbezüglich verändern (es zumindest versuchen). Edit: Es gelang. Allerdings sehe ich es weiterhin als ein wenig günstiger an, die Spaltenbreitenmessung nicht einzunullen, sondern gleich mit den Zellenbreiten irgendeiner Zeile (beispielsweise mit den Einträgen des Tabellenkopfes) zu beginnen.

Der Löwenanteil an der Langsamkeit meines Codes steckt allerdings in der Größenanpassung des Formulares: Pixelweise (!) wird dessen Größe verändert und jedesmal das Vorhandensein eines Scrollbalkens geprüft. Dafür ist das Formualar dann aber auch exakt angepaßt. Nur nach der Stringgridgröße zu gehen, funktioniert nämlich aufgrund der verschiedenen "Themes" in XP, Vista, 7 & Co. (Luna, Aero...) nicht so, wie es mir vorschwebt.

Zitat:

Zitat von blauweiss (Beitrag 1059006)

Zitat:

Zitat von Delphi-Laie (Beitrag 1058707)

Das mit dem Constrain stimmt: Das Fenster ist merkwürdigerweise auf 112 Pixel (das Minimum) voreingestellt, so daß die Dekrementierungsschleife natürlich endlos wird. Merkwürdig, wenn die Codezeilen direkt verwende, funktionieren sie tadellos.... Danke auch für diesen Hinweis!

Ich will Dir nicht zu nahe treten, aber das halte ich für ausgeschlossen.

112 Pixel als Formularbreite lassen sich nach meiner Recherche nicht unterschreiten. Doch das ist ohnehin obsolet, weil der Prozeduraufruf fehlerhaft war.

Zitat:

Zitat von blauweiss (Beitrag 1059006)

Deine Reaktion auf Foristen, die Dir helfen wollen, ist ungewöhnlich. Die Herangehensweise an Deine Probleme, Deine Problembeschreibungen sowie die Reaktion auf Vorschläge Anderer scheint mir nicht professionell. Das ist nicht überheblich, denn Du wirst wohl nicht professionell (beruflich) programmieren, oder ?

Diese wohl eher rhetorisch gemeinte Frage dürfte schon mein selbstredendes Pseudonym beantworten. Nun, ich fragte ursprünglich, wie man die Formulargrößeanpassung in einem Unterprogramm vereinigen, zentralisieren kann, so daß man den dafür relevanten Code nicht mehrmals im Programm aufführen muß. Den entscheidenden Hinweis dazu erhielt ich (auf den ich nicht kam und auch nie gekommen wäre, weil er mit meinen aus Turbo-Pascal-Zeiten erworbenen Pascal-Kenntnissen nicht kompabitbel ist). Das andere, was hier zusätzlich noch kam, fragte ich gar nicht, doch auch das nehme ich als Anregungen gern und dankend mit und probiere auch einen Großteil davon aus und übernehme es ggf. - auch wenn ich mich nicht zu allem äußere. Du kannst aber nicht erwarten, daß ich alles, was ich an Hinweisen bekomme, auch umsetze oder auch nur vorbehaltlos und unkritisch gutheiße, nur, weil Du vielleicht ein (studierter) Informatiker und/oder ein beruflicher Programmierer bist. Zudem weiß ich, welche Mühe eine Forumstätigkeit schon dann macht, wenn man um die fachlichen Antworten nicht verlegen ist, und weiß deshalb Hilfe durchaus zu schätzen (schau mal, in wievielen Diskussionen nicht einmal ein einziger Dank kommt!). Solltest Du anzudeuten beabsichtigen, daß ich undankbar und/oder ein unbelehrbarer Sturkopf sei, dann verwahre ich mich dagegen.

Gruß

Delphi-Laie