Rewrite(f) findet File nicht...

[Sir Rufo]

Zitat von calibra301:

@Rufo...Stadthagen ??
Da brauche ich ja nur mal laut ausm Fenster zu rufen...bin aus Rosenhagen, hinter Wiedensahl

Wenn der Kanal da mal nicht das Rufen verschluckt ... ich höre hier nix

[calibra301]

Welche Chancen hab ich denn das als offen detektierte File zu schliessen
und zu löschen ?

Nicht das sich rausstellt das das alte D6 und W7 bei irgendwelchen Fileoperationen nicht das machen
was sie sollen...

Eim "Umzug" mit diesem Projekt (DLL, incl . Alphatools ) wird bestimmt auch nicht ganz ohne sein.

[FarAndBeyond]

Zitat:

Wenn du eine Exception wirfst, dann wird der Code danach nicht mehr ausgeführt. Ein Exit dahinter ist überflüssig.
try
except
Exit;
end;
ist so mit das Schlimmste, was man machen kann. Das geht in Richtung Quanten-Computer => ja, nein, eventuell vielleicht (warum auch immer oder nicht)

Das liegt aber stark daran wo man sich gerade befindet. Wenn ich im OnClose der Form noch was speichern möchte und es kommt zu einer Exception, dann bleibt ohne EXIT ein Teil des Programms im "TaskManager" hängen, da OnDestroy nicht mehr durchlaufen wird.

In diesem Beispiel sorgt EXIT dafür, dass Closefile(f); nicht mehr durchlaufen wird, was also ungünstig ist...

In D7 wird nach einer Exception der Code innerhalb von Try .. Except nicht mehr durchlaufen, aber der restliche Code innerhalb der Prozedur wird ganz normal durchlaufen...

[calibra301]

Gebe erstmal auf....

Keinen Plan....

Komisch: Nach dem erstem speichern was ja klappt hab ich versucht die Datei
per Explorer zu löschen -> geht, ist also geschlossen.

Es wird definitiv kein weiteres Assignfile angesprungen welches diese Datei
öffnet. Nach dem nächstem Versuch diese Settings zu speichern kommt bei rewrite
die Exception ( nicht bei FileisOpen !! ) und DANACH hab ich eine 0Kb Datei die sich
nicht löschen lässt.

Hab bei Herrn Amazon nun ne XE8 Pro gekauft. Hoffe der Umstieg wird keine
Katastrophe..

[zeras]

Vielleicht macht auch dein Virenscanner Probleme?
Du kannst ja auch mal eine kurze Zeit warten und dann nochmal versuchen.

[FarAndBeyond]

Ich würde grundsätzlich immer try..finally innerhalb von try..except benutzen...
Der Schutzblock steht ja auch bei SirRufo schon mit drin...

Delphi-Quellcode:

Function CDevice.storerSettings(name: string) : integer;
 Var 
  i: integer;
  f: file of TPSettingsFile;
  s: TSettingsFile;
 Begin
  Try 
   storeSettings := -1;
    If Not FileExists( name ) 
    Then raise EInOutError.CreateFmt( 'File %s does not exists!', [name] );
  
    If IsFileInUse( name ) 
    Then raise EInOutError.CreateFmt( 'File %s is open!', [name] );
    
   AssignFile(f, name);
    Try   
     Rewrite(f);
     s.magic := $537916;
     //...usw.
     Write(f, s);
    Finally
     Try
      Closefile(f); // oder direkt in separater, abgesicherter Prozedur... 
      storeSettings := 0;
     Except
      Info + StandardExceptionHandling.... was auch immer... 
      storeSettings := -1;
     End;
    End;
  Except
   // Standard ExceptionHandling, was auch immer man möchte... 
  End;
 End;

Ist halt immer die Frage wie detailiert braucht man ein ExceptionHandling... schließlich kann man das noch um einiges erweitern...

[Sir Rufo]

Versuch mal die Methode zu beschreiben (dokumentieren). Wenn du einen Roman dazu schreiben musst, dann machst du dort zu viel.

Und ein try except was die gesamte Methode umschliesst, die eine echte Arbeit erledigt, ist vom Konzept her falsch.

Die Methode vorher, die diese aufruft, legt den Namen fest. Dort hätte ich eine Möglichkeit vernünftig auf diese Exceptions zu reagieren (z.B. einen anderen Dateinamen). Also kommt das Exception-Handling dort hinein, oder man lässt die einfach hochpoppen.

[mm1256]

Ich vermute, dass das wahre Problem nicht in dieser Funktion liegt, sondern schon vorher irgendwas Dummes passiert, z.B. Speicher überschrieben. Beim "Wiederholen" tritt es dann auf. Darum würde ich erst mal mit

Code:

{$Q+,R+, D+, L+}

compilieren und dann müsste man doch was sehen?