[gelöst] Problem mit DeleteFile (Got "AnsiString", expected "PChar")

[charlytango]

Hi,
ich fürchte, irgendwie sehe ich den Wald vor lauter Bäumen nicht.

Ich habe Probleme mit DeleteFile. Eigentlich hat das immer geklappt, habe ich da eine falsche Unit in der uses Klausel?
Sysutils scheint nicht zu funktionieren. Erstaunlicherweise akzeptiert der Compiler die String-Übergabe bei FileExists und bei DeleteFile wird gemeckert.

Code: Alles auswählen

uses
  Classes, SysUtils, forms, dialogs {$ifdef WINDOWS},WinDirs, Windows{$endif};
...
function GuessSQLDatabaseFile(bDeleteOldFile:boolean=false):string;
...
implementation
...

function GuessSQLDatabaseFile(bDeleteOldFile: boolean): string;
var
  sSearchedin:string;
  sPathString:string;
begin
  result:=cUNDEF;
  sSearchedin:='';

  {$ifdef Unix}
  sPathString:='data@sql';
  {$else}
  sPathString := 'data@sql';
  {$endif}

  result:=GuessFile(cSQLDatabaseFile,sPathString,sSearchedin);

  if result=cUNDEF  then begin
    MyBigDialog('',tdiWarning, LineEnding
                + rs_ErrFileName + {$INCLUDE %FILE%} + LineEnding
                + rs_ErrMethodName +  {$I %CURRENTROUTINE%} + LineEnding
                + rs_ErrLinenumber + {$INCLUDE %LINE%} + LineEnding +LineEnding
                + rs_ErrTtfSQLDatafile // 'tried to find SQL data File in'
                + LineEnding + LineEnding
                + sSearchedin
                + rs_ErrWasnotfound + LineEnding+ LineEnding
                + format(rs_ErrPleaseProvide,[cSQLDatabaseFile])+ LineEnding+ LineEnding  //'Please provide '  + cSQLDatabaseFile +' in one of the searchpaths'
                + format(rs_ErrTtfSQLCreatingDatafile,[cSQLDatabaseFile]) //' creating standard database file '+cSQLDatabaseFile+' in application directory instead');
                );

    result:=cSQLDatabaseFile;
  end;

  if bDeleteOldFile then begin
    if FileExists(result) then begin
      DeleteFile(result);  //HIER kracht es
      //Error: Incompatible type for arg no. 1: 
      //Got "AnsiString", expected "PChar"
    end;
  end;

end; 

Ein Casting auf pChar ( DeleteFile(pchar(result)); ) wird akzeptiert, aber irgendwie verstehe ich nicht dass es früher funktioniert hat und jetzt nicht. Kann mich da bitte jmd erleuchten?

[theo]

Bin zwar nicht auf Win, aber ich tippe mal drauf, dass der "DeleteFile" der Unit Windows meint?
Probier mal Sysutils.Deletefile oder die "uses" umzusortieren.

[Ekkehard]

Ich habe Probleme mit DeleteFile. Eigentlich hat das immer geklappt, habe ich da eine falsche Unit in der uses Klausel?
Sysutils scheint nicht zu funktionieren.

Code: Alles auswählen

uses
  Classes, SysUtils, forms, dialogs {$ifdef WINDOWS},WinDirs, Windows{$endif};

Ein Casting auf pChar ( DeleteFile(pchar(result)); ) wird akzeptiert, aber irgendwie verstehe ich nicht dass es früher funktioniert hat und jetzt nicht. Kann mich da bitte jmd erleuchten?

Das Problem liegt in der Reihenfolge der Units. Die Unit Windows deklariert die gleiche Funktion mit PChar.
Sortiert man die Units um, so dass SysUtils am Ende steht klappts wieder:

Code: Alles auswählen

uses
  Classes, forms, dialogs {$ifdef WINDOWS},WinDirs, Windows{$endif}, SysUtils;

Alternativ kann man auch die Unit angeben

Code: Alles auswählen

  SysUtils.DeleteFile(fn);        

dann geht es auch.

Schönen Sonntag,
Gruß Ekkehard

[charlytango]

ok, das mit dem Umsortieren der Units klappt -- danke.
Auf die Idee kam ich ja auch schon, aber ich dachte nicht dass die von hinten nach vorne priorisiert werden ?

Aber dann habe ich als Folge ein anderes Problem:
Natürlich habe ich geprüft (mit Alt - Mausklick), welche Funkrion verwendet wird.
Bei mir ist die IDE aber nach SysUtils gesprungen und hat mir nicht die beim Kompilieren verwendete Funktion aus der Unit Windows angezeigt.

Die header der Funktionen stehen in filutilh.inc, die Funktionen in filutil.inc, die beide erst in sysutils.ch included werden, was wiederum in sysutils.pp included wird.

Letztlich bleibt die Frage, warum mir in der GUI eine andere Funktion gezeigt wird als dann beim Kompilieren verwendet wird ?

[Warf]

Naja also grundsätzlich ist's erst Mal so das Lazarus zum Parsen des Codes seine eigenen codetools benutzt die unabhängig vom FPC parser entwickelt werden und daher kommt es ab und an zu unterschiedlichen "Interpretationen" des Codes.

Das hier ist vermutlich ein bug in Lazarus, denn wie es für mich aussieht sucht Lazarus einfach alle überladenen Funktionen, und sucht sich dann die aus die am besten passt. Das ist auch grundsätzlich korrektes verhalten, unit übergreifend nur wenn die Funktionen mit overloaded getahged sind: https://www.freepascal.org/docs-html/ref/refse96.html

Prior to version 1.9 of the compiler, the overloaded functions needed to be in the same unit. Now the compiler will continue searching in other units if it doesn’t find a matching version of an overloaded function in one unit, and if the overload keyword is present.

If the overload keyword is not present, then all overloaded versions must reside in the same unit, and if it concerns methods part of a class, they must be in the same class, i. e. the compiler will not look for overloaded methods in parent classes if the overload keyword was not specified.

Kann man also eigentlich als bug reporten

[Mathias]

ok, das mit dem Umsortieren der Units klappt -- danke.
Auf die Idee kam ich ja auch schon, aber ich dachte nicht dass die von hinten nach vorne priorisiert werden ?

Man sollte sich daran gewöhnen, die Unit windows im als erstes zu nehmen. Da bin auch schon darüber gestolpert.

Ich mache es nach Möglichkeit immer so.
OS spezifische Units -> RTL -> LCL -> fremde Packages -> eigenen Packages -> lokale Units.

[charlytango]

wieder etwas dazu gelernt -- vielen Dank.

[Zvoni]

Ich glaube mich daran zu erinnern, dass die Reihenfolge der Uses-Klausel nach dem Motto "Der letzte macht das Licht aus" funktioniert.
Heisst: Die Deklaration, welche in der am weitesten hinten in "Uses" genannten Unit gefunden wird, wird benutzt, sofern oben genannte "Spezifikationen" nicht verwendet werden.

[Niesi]

ok, das mit dem Umsortieren der Units klappt -- danke.
Auf die Idee kam ich ja auch schon, aber ich dachte nicht dass die von hinten nach vorne priorisiert werden ?

Man sollte sich daran gewöhnen, die Unit windows im als erstes zu nehmen. Da bin auch schon darüber gestolpert.

Ich mache es nach Möglichkeit immer so.
OS spezifische Units -> RTL -> LCL -> fremde Packages -> eigenen Packages -> lokale Units.

Danke für den Hinweis - die lokalen Units hatte ich tatsächlich immer zuletzt eingefügt. Einfach, um da immer den Überblick haben zu können - das mit dem OS-Zeugs ist neu und wichtig für mich ...

[charlytango]

Dann war es ja doch nützlich dass mir das passiert ist.
Danke allseits, Case closed (sofern nicht nich neue Erkenntnisse reinkommen ggg)

[af0815]

Wenn man sich nicht sicher ist, so kann man immer den Unitnamen vorne ransetzten, dann wird das nicht gesucht, sondern die spezifizierte Routine direkt genommen. Besonders wenn man so ein komisches Verhalten hat, kann das auch mal ein Test sein, ob das richtige gefunden wird.

Mir ist das speziell bei OS-spezifischen Sachen, bei close (Neu deswegen:FileClose) und bei der unit Math begegnet.

[greye]

Ich glaube mich daran zu erinnern, dass die Reihenfolge der Uses-Klausel nach dem Motto "Der letzte macht das Licht aus" funktioniert.

Was ja eigentlich auch logisch ist. Wenn was deklariert wird, und später wird was mit dem gleichen Namen neu deklariert, dann gewinnt das, was zuletzt festgelegt wurde.
Aber wem erzähle ich das? Ihr seid da wohl eher die Profis und ich bin neu hier. Apropos neu: Hallo zusammen

In dem Zusammenhang und eher OT: Ich finde das Forum klasse, ich lese sehr gerne hier und auch der Thread trägt zu meinem Erkenntnisgewinn bei. Danke dafür.

[Mathias]

Besonders wenn man so ein komisches Verhalten hat, kann das auch mal ein Test sein, ob das richtige gefunden wird.

Es gibt noch was gemeineres. Erstelle mal ein ganz normales LCL-Programm und bennen dort eine Unit "cairo.pas". Als Anfänger kann man da recht lange suchen, warum das Programm nicht mehr geht.