[gelöst] Lazarus: SaveToFile geht nicht

[Kralle]

OS: Windows 8.1 Professional 64-Bit
Dateisystem: NTFS
IDE: Lazarus 1.2.6
FPC: 2.6.4

Moin,

wedwer das :

Delphi-Quellcode:

procedure TForm1.MenuItem5Click(Sender: TObject);
var tempstr: string;

begin

 if SaveDialog1.Execute then
 begin
      tempstr:=SaveDialog1.FileName;
      sl.SaveToFile(tempstr);
 end; 
end;

noch das :

Delphi-Quellcode:

procedure TForm1.MenuItem5Click(Sender: TObject);

begin

 if SaveDialog1.Execute then
      sl.SaveToFile(SaveDialog1.FileName);
 end;

Funktionieren. Beim ersten steht der richtige Pfad beim Debug in der Variablen,
aber das Speichern führt bei beiden trotzdem zu der Meldung:

Zitat:

Projekt .. hat Exception-Klasse >>External: SIGGEGV<< ausgelöst. Bei Adresse 4441434C

Warum? Was läuft da falsch?

Gruß heiko

[baumina]

Was ist s1, wo wurde das kreiert?
Beim 2. Beispiel ist tempstr nicht zugewiesen.

[DeddyH]

Die nötigen Rechte sind aber vorhanden? Und wozu der temporäre String, sofern er nicht anderweitig noch gebraucht wird?

Delphi-Quellcode:

if SaveDialog1.Execute then
  sl.SaveToFile(SaveDialog1.Filename);

[mjustin]

SIGSEGV (segmentation violation) entspricht einer Access Violation (siehe http://en.wikipedia.org/wiki/Segmentation_fault).

Bei der Variablen sl (SL) handelt es sich dann vermutlich eine nicht instanziierte TStringList.

[Kralle]

Moin,

Zitat:

Zitat von baumina (Beitrag 1290186)

Was ist s1, wo wurde das kreiert?

sl ist eine StringList die Gobaldefiniert wurde und in Form.Create erzeugt wird.
Das Füllen der Liste funktioniert.

Zitat:

Zitat von baumina (Beitrag 1290186)

Beim 2. Beispiel ist tempstr nicht zugewiesen.

Tippfehler - berichtigt.

Kann es sein das es irgendein Problem mit den Zeichensätzen zwischen Lazarus/Free Pascal und Windows ist?

Gruß HEiko

[BadenPower]

Zitat:

Zitat von mjustin (Beitrag 1290196)

SIGSEGV (segmentation violation) entspricht einer Access Violation (siehe http://en.wikipedia.org/wiki/Segmentation_fault).

Bei der Variablen sl (SL) handelt es sich dann vermutlich eine nicht instanziierte TStringList.

Nicht nur vermutlich.

Die Fehlermeldung kommt, wenn auf ein Objekt zugegriffen werden soll, welches nicht erstellt wurde.

sl ist eine Stringlist (vergleiche andere Posts des TE), welche nicht erstellt wurde (also kein Create).


Zeig uns einmal die "FormCreate"-Procedure.

[Kralle]

Moin,

Zitat:

Zitat von DeddyH (Beitrag 1290187)

Die nötigen Rechte sind aber vorhanden?

Ja.

Zitat:

Zitat von DeddyH (Beitrag 1290187)

Und wozu der temporäre String, sofern er nicht anderweitig noch gebraucht wird?

Delphi-Quellcode:

if SaveDialog1.Execute then
  sl.SaveToFile(SaveDialog1.Filename);

Um zu sehen ob Filename irgendwelche "ulkigen" Zeichen aufgrund irgendwelcher Schriftsatzproblem enthält.

Gruß HEiko

[DeddyH]

Zeig mal mehr Code, das wird sonst ein lustiges Rätselraten. Die Stringliste existiert zu diesem Zeitpunkt auf jeden Fall, oder wird sie ggf. vor dem FormDestroy wieder freigegeben?

[mjustin]

Zitat:

Zitat von Kralle (Beitrag 1290198)

sl ist eine StringList die Gobaldefiniert wurde und in Form.Create erzeugt wird.
Das Füllen der Liste funktioniert.

Wird der richtige Inhalt der StringList im Debugger angezeigt bevor der SaveToFile Aufruf stattfindet?

[Kralle]

Mpoin,

Zitat:

Zitat von mjustin (Beitrag 1290196)

SIGSEGV (segmentation violation) entspricht einer Access Violation (siehe http://en.wikipedia.org/wiki/Segmentation_fault).

Bei der Variablen sl (SL) handelt es sich dann vermutlich eine nicht instanziierte TStringList.

Also, sl ist eine StringList und ja sie ist instanziiert, sonst könnte ich sie ja nicht mit Inhalten zur Laufzeit befüllen oder?

Delphi-Quellcode:

  private
    { private declarations }
  public
    { public declarations }
  end;

var
  Form1: TForm1;
  sl: TStringList;
implementation

{$R *.lfm}

{ TForm1 }

procedure TForm1.FormCreate(Sender: TObject);
begin
   sl:= TStringList.Create;
end;

Gruß HEiko

[DeddyH]

Wo gibst Du die Liste wieder frei?

[BadenPower]

Schmeiss einmal den ganzen Code rüber.

Ich hab es beim mir unter Lazarus getestet und es funktioniert perfekt.

Wahrscheinlich löst noch etwas Anderes den Fehler aus.
Das ist nur eine Vermutung, denn auch Deine Diagnose der Fehlerstelle beim StringGrid.RowCount ist falsch gewesen.

[Kralle]

Moin,

Zitat:

Zitat von mjustin (Beitrag 1290202)

Wird der richtige Inhalt der StringList im Debugger angezeigt bevor der SaveToFile Aufruf stattfindet?

Hmm, gute Frage. Irgendwie bekomme ich es in Lazarus nicht hin, das mir der Inhalt von sl bei den Überwachten Ausdrücken angezeiigt wird.
Kannst Du helfen?

@DeddyH: Die Liste gebe ich hier wiedwer frei:

Delphi-Quellcode:

procedure TForm1.FormCloseQuery(Sender: TObject; var CanClose: boolean);
begin
    sl.free;
end;

Gruß Heiko

[Kralle]

Was mich verwirrt ist der Inhalt von

Delphi-Quellcode:

SaveDialog1.FileName

dem dem Schliessen des Dialoges.

Zitat:

<Error: A syntax error in expression, near 'FileNAme'.>

Heiko

[DeddyH]

FormCloseQuery ist die völlig falsche Stelle. Was man im FormCreate erzeugt, gibt man i.A. erst im FormDestroy wieder frei.

[Kralle]

Moin,

Zitat:

Zitat von BadenPower (Beitrag 1290208)

Schmeiss einmal den ganzen Code rüber.

Nicht mehr nötig.

Erst wurde die StringList in einer ButtonClick-Ereignis-Behamndlungsprocedure
Erzeugt und nach einem finally wieder freigegeben.

Leider habe ich nur einen Teil davon ausgelagert, so das die StringList doch vor dem Speichern ein Free bekam.

Fehler gefunden. Danke für Eure schnelle Hilfe.

Das Free habe ich ins Destroy verschoben.

Gruß HEiko

[himitsu]

Warum heißt das "sl"?

Und wieso ist das global?

[BadenPower]

Ausserdem solltest Du noch Deine Schleife aus dem anderen Post von:

Delphi-Quellcode:

   StringGrid1.RowCount:=sl.count+StringGrid1.FixedRows;
    for i := 0 to sl.count-1 do
        begin
         StringGrid1.Rows[i+1].StrictDelimiter := True;
         StringGrid1.Rows[i+1].CommaText:=sl.Strings[i];
   end;

auf:

Delphi-Quellcode:

   StringGrid1.RowCount := sl.count + StringGrid1.FixedRows;
    for i := 0 to sl.count-1 do
        begin
         StringGrid1.Rows[i+StringGrid1.FixedRows].StrictDelimiter := True;
         StringGrid1.Rows[i+StringGrid1.FixedRows].CommaText:=sl.Strings[i];
   end;

ändern.

Denn wenn Du im OI die Property FixedRows des Stringgrids änderst, dann würde es bei Deiner Variante wieder zum Fehler kommen.

[Kralle]

Zitat:

Zitat von BadenPower (Beitrag 1290216)

Delphi-Quellcode:

   StringGrid1.RowCount := sl.count + StringGrid1.FixedRows;
    for i := 0 to sl.count-1 do
        begin
         StringGrid1.Rows[i+StringGrid1.FixedRows].StrictDelimiter := True;
         StringGrid1.Rows[i+StringGrid1.FixedRows].CommaText:=sl.Strings[i];
   end;

ändern.

Denn wenn Du im OI die Property FixedRows des Stringgrids änderst, dann würde es bei Deiner Variante wieder zum Fehler kommen.

Okay, danke für den Hinweis. Habe das sofort umgesetzt.

Gruß Heiko

[Kralle]

Moin,

Zitat:

Zitat von himitsu (Beitrag 1290215)

Warum heißt das "sl"?

Weil

Delphi-Quellcode:

StringListen

irgendwie hier in den Beispielen immer "sl" heißen.

Zitat:

Zitat von himitsu (Beitrag 1290215)

Und wieso ist das global?

Weil ich mein StringListe nicht in einer Procedure/Funktion definiere sondern halt global.

Gruß Heiko

[BadenPower]

Zitat:

Zitat von Kralle (Beitrag 1290224)

Moin,

Zitat:

Zitat von himitsu (Beitrag 1290215)

Und wieso ist das global?

Weil ich mein StringListe nicht in einer Procedure/Funktion definiere sondern halt global.

Das kracht dann früher oder später schon wieder.

Leg die Defintion von sl in die Typdeklaration der Form.

Delphi-Quellcode:

  TForm1 = class(TForm)
  private
    { private declarations }
   sl: TStringList;
  public
    { public declarations }
  end;

Dann ist sie in der gesamten Form sichtbar, aber vor unbeabsichtigten Änderungen von ausserhalb geschützt.

Stell Dir einfach einmal vor, was geschiet, wenn Du diese Form zweimal erstellst, oder wenn irgend ein Komponentenentwickler auf die glorreiche Idee kommt, eine globale Variable mit dem Namen "sl" anzulegen.

[himitsu]

Oder wenn du auf die geniale Idee kommt und irgendwo nochmal eine globale StringListe brachst und denkst "oh, cool, da ist ja schon eine".

Alles was nicht lokal ist, muß einen sprechenden Bezeichner bekommen, der nicht das Datenformat beschreibt, sondern den "Inhalt".
Sonst könnte man alle globalen Integer auch i1 bis i3296 benennen.

[Kralle]

Moin,

Zitat:

Zitat von BadenPower (Beitrag 1290234)

Leg die Defintion von sl in die Typdeklaration der Form.

Delphi-Quellcode:

  TForm1 = class(TForm)
  private
    { private declarations }
   sl: TStringList;
  public
    { public declarations }
  end;

Dann ist sie in der gesamten Form sichtbar, aber vor unbeabsichtigten Änderungen von ausserhalb geschützt.

Stell Dir einfach einmal vor, was geschiet, wenn Du diese Form zweimal erstellst, oder wenn irgend ein Komponentenentwickler auf die glorreiche Idee kommt, eine globale Variable mit dem Namen "sl" anzulegen.

Und wieder was gelernt. Danke, habe das gleich umgesetzt.

Gruß Heiko

[Kralle]

Moin,

Zitat:

Zitat von himitsu (Beitrag 1290236)

Oder wenn du auf die geniale Idee kommt und irgendwo nochmal eine globale StringListe brachst und denkst "oh, cool, da ist ja schon eine".

Alles was nicht lokal ist, muß einen sprechenden Bezeichner bekommen, der nicht das Datenformat beschreibt, sondern den "Inhalt".
Sonst könnte man alle globalen Integer auch i1 bis i3296 benennen.

Da sollte ich das Refactoring mal anschmeissen und die Variablen, Liste usw. sinnig benennen.
Danke.

Gruß Heiko