[gelöst] StringGrid Col- und Row- Anpassung scheitert

[Erwin]

Hallo Zusammen.

Habe derzeit ein Problem, das ich nicht begreife, weil es vorher in ähnlichen Fällen (Anwendungen) nicht aufgetreten ist. Ich habe eine StringGrid ins Formular gesetzt. Diese hat die Ausgangseinstellung von 10 ColCount und 10 RowCount. Im laufe der Zeit kommen weiter Spalten und Zeilen dazu, was ich zuerst mit ColCount+Anzahl (und RowCount + Anzahl) erweitere und dann diese Cells fülle. Dann speichere ich das Ganze mittels SaveToFile. Wenn ich nach Neustart der Anwendung dann die vorherige Datei mit LaodFromFile wieder lade, bleibt die Anzahl der ColCount und RowCount des betreffenden StringGrid dennoch bei 10, und das obwohl zuletzt, als ich (den Inhalt) gespeichert hatte, es weit über 10 war.

In der Vergangenheit mit anderen Programmen hat es funktioniert. Trotz Vergleiche aber was bei den anderen anders sein könnte, kann ich keinen Unterschied feststellen. Was übersehe ich?

Danke.

Gruß, Erwin.

[Erwin]

Tja ... nach dem ich es so gründlich beschrieben hatte, ging mir vor allem die Art und Weise des Speichern nicht aus dem Kopf. Ich stellte bei erneutem Vergleichen fest, dass ich beim Vergleichen eines anderen Programms nur eine StringGrid dabei war, dich so wie vorher beschrieben, die Daten gespeichert hatte. Bei all den anderen stellte ich fest, dass ich SaveToCSVFile und LoadFromCSVFile nutzte. Mit diesen Speicher-Format klappt es. Hat sich also erledigt. Sorry für den Text-Müll.

[af0815]

+1 für die gepostete Erkenntnis. Ohne Spass, auch das ist wichtig, zu erkennen und schreiben, wo das Problem war.

[wp_xyz]

Kein TextMüll: Es geht auch mit SaveToFile/LoadFromFile. Denn das Grid verwendet ein Property SaveOptions, mit dem man festlegen kann, was alles gespeichert werden soll (https://wiki.lazarus.freepascal.org/Gri ... ring.29.3B)

Code: Alles auswählen

type
  TGridSaveOptions = (
    soDesign,             // Save grid structure (col/row count and Options)
    soAttributes,         // Save grid attributes (Font,Brush,TextStyle)
    soContent,            // Save Grid Content (Text in StringGrid)
    soPosition            // Save Grid cursor and selection position
  );
  TSaveOptions = set of TGridSaveOptions; 
  
const
  soAll: TSaveOptions = [soDesign, soAttributes, soContent, soPosition];   

Im Constructor werden SaveOptions lediglich auf soContent eingestellt. Wenn du alles gespeichert haben willst, setze vor dem Speichern (und später auch beim Lesen) SaveOptions of soAll, zumindest aber auf [soContent, soDesign].

[Erwin]

Kein TextMüll: Es geht auch mit SaveToFile/LoadFromFile. Denn das Grid verwendet ein Property SaveOptions, mit dem man festlegen kann, was alles gespeichert werden soll ...

Leider kann man das nicht im Objektfenster einstellen. Für meine Zwecke ist eh das andere Format zum Speichern sogar doppelt vorteilhaft: Geht mit weniger Schreibarbeit und das Format ist für mich praktischer für eventuelles weiter verarbeiten. Ist aber ganz schön gut versteckt. Auch müsste ich mich damit erst mal auseinander setzen. Vielleicht mache ich das auch, um auch so was ... zu verstehen. Dieses Ein- und Aus-Schalterzeug mittels Quelltext, ... glaube durch Objektinspektor, wo man nur einen Hacken machen muss, hat man wohl den direkten Umgang verlernt, bzw. wenn man wie ich erst mit Delphi/Lazarus richtig los gelegt hat, es gar nicht erst gelernt. Es ist mir jedenfalls sehr Fremd ... irgendwie ... fühle mich dabei eben unwohl.

[wp_xyz]

Ich weiß nicht, warum der Autor der Komponente (Jesus Reyes) sich dafür entschieden hat, die SaveOptions nur als "public" zu deklarieren (damit taucht die Einstellung im Objektinspektor nicht auf). Somit ist die Einstellung schwer(er) zu finden.

Andererseits haben "published" Properties (die im Objektinspektor sichtbar sind) auch Nachteile, denn sie erschweren das Bearbeiten eines Projekt mit verschiedenen Versionen von Lazarus. Eine im Quellcode gesetzte Eigenschaft kann man durch eine Versionsabfrage {$IF LCL_FullVersion ...} in der richtigen Version unterbringen, in der LFM-Datei geht das jedoch nicht - die IDE verweigert das Laden eines Formulars mit unbekannten Properties in der LFM-Datei.

Deine Abneigung, eine Änderung im Quelltext vorzunehmen, kann ich aber nicht nachvollziehen. Wie schreibst du denn den Rest des Programms, den man nicht im Objekt-Inspektor anklicken kann?

[Erwin]

Ich weiß nicht, warum der Autor der Komponente (Jesus Reyes) sich dafür entschieden hat, die SaveOptions nur als "public" zu deklarieren (damit taucht die Einstellung im Objektinspektor nicht auf). Somit ist die Einstellung schwer(er) zu finden.

Ach ja, da war was wegen Public und dem anderem bei Erstellung von Komponenten. Aber die 2, 3 Beschreibungen zum erstellen von so was, die ich mal las, war mir dessen Erklärung/Beschreibung so ... verworren, dass ich mich aus Eigenschutz (man will ja nicht seinen Verstand verlieren) nicht näher damit befasst habe.

Andererseits haben "published" Properties (die im Objektinspektor sichtbar sind) auch Nachteile, denn sie erschweren das Bearbeiten eines Projekt mit verschiedenen Versionen von Lazarus. Eine im Quellcode gesetzte Eigenschaft kann man durch eine Versionsabfrage {$IF LCL_FullVersion ...} in der richtigen Version unterbringen, in der LFM-Datei geht das jedoch nicht - die IDE verweigert das Laden eines Formulars mit unbekannten Properties in der LFM-Datei.

Da ist Vieles was ich nicht verstehe, außer den Punkt, dass es also sein kann, dass eine älteres Projekt sich mit neuem Lazarus-Versionen sich nicht richtig Kompilieren lassen? Deshalb hasse ich neue Versionen. Sind oft nicht abwärtskompatibel, und für mich betreffend, nichts wirklich brauchbar neues dabei.

Deine Abneigung, eine Änderung im Quelltext vorzunehmen, kann ich aber nicht nachvollziehen. Wie schreibst du denn den Rest des Programms, den man nicht im Objekt-Inspektor anklicken kann?

Nicht Abneigung, würde eher sagen: Unwohlsein. Fühle mich dabei Unwohl, weil ich nicht wirklich nach vollziehen kann, was und wie das passiert. Bei einfachen Dingen, wie Breite, Farbe etc. kein Problem. Das nutze ich Ständig im Quellcode. Einfache Ja- und Nein-Schalter auch kein Problem. Aber so was wie ... Unterstreichen von Schrift ... da müsste ich es wieder 1:1 aus meinem Buch abschreiben, und verstehe dennoch nicht wirklich, wie und wieso das geht? Das wirkt für mich ganz anders als einfaches ja und nein, sondern eher etwa abstrakt, was mich verunsichert. Und hier ist dann auch beides: Versteckt und irgendwie abstrakt.
Irgendwas war da mal, wo im Objektinspektor für eine Grafische Komponente keine Farbe vorhanden war, was ich dann einfach im Quelltext versuchte und ging. Da hatte ich wiederum keine Bedenken.
Und was den Rest betrifft: Je nach dem, wenn ich es verstehe, und einfach ist oder mir verständlich wo erklärt wurde, nutze ich es. Aber Anderes ... wo nicht erklärt wird, wozu es gut sein soll, viele neue Befehle auftauchen, alles mit Warnungen und zugleich als Leicht umschrieben wird ... . Da komme ich mich recht verloren vor, und weiß auch außerdem eh nicht, was ich damit anfangen soll?