Rückgabewert der Funktion undefiniert

[trebor90]

Hallo Delphianer(innen)!

Ich weiß, ich habe schon öfter im Forum Themen zu folgender bekannter Fehlermeldung gehört: "Rückgabewert der Funktion FormX.Funktion könnte undefiniert sein".
Aber ich komme echt nicht weiter - ich zerbreche mir über den paar Zeilen Code schon Wochen den Kopf:

Delphi-Quellcode:

//Dateien des gleichen Pfads schon vorhanden?
function TForm1.schonda(s:string):boolean;
var i,a:integer;
begin
a:=listbox1.items.count;
for i:=1 to a do
  if (s=listbox1.items[i-1]) then
    begin
      result:=true;
      break;
    end
  else result:=false;
end;

Schonda soll prüfen, ob ein Element s:string (hier: eine Datei) in einer Listbox schon vorhanden ist.
Ich ziehe Dateien per Drag'n'Drop hinein und es wäre ja sichtbar dumm, wenn zweimal der gleiche Dateiname in der Listbox vorhanden ist.
Schonda prüft also bevor eine Datei der Listbox hinzugefügt wird ...


Hoffe, ihr könnt mir helfen - RObert

[quendolineDD]

Wenn die Schleife nicht durchlaufen wird, wird kein Result gesetzt. Denk mal darüber nach, was passiert, wenn 0 Elemente in der Listbox sind.
Außerdem gab es doch bei Listbox die Funktion .IndexOf[].

Edit:
Dann würde ich lieber eine while- oder repeat-Schleife nehmen, anstatt mit einem break zu arbeiten. Und das false kannst du ja schon ganz am Anfang setzen und nur noch bei einem Fund den Rückgabewert auf true ändern.

[mirage228]

Zitat von quendolineDD:

Edit:
Dann würde ich lieber eine while- oder repeat-Schleife nehmen, anstatt mit einem break zu arbeiten. Und das false kannst du ja schon ganz am Anfang setzen und nur noch bei einem Fund den Rückgabewert auf true ändern.

Bei einer for-Schleife wird auf Items.Count aber nur einmal zugegriffen und nicht bei jeder Iteration (falls das Wichtig sein sollte...).

[quendolineDD]

Heißt doch nicht, das hier jedes mal auf .Count zugegriffen werden muss.

[mirage228]

Zitat von quendolineDD:

Heißt doch nicht, das hier jedes mal auf .Count zugegriffen werden muss.

Hm, dasn Argument
Wobei man sich für sehr große Dateilisten eh nen besseren Such-Algo (ggf. auch nicht mit TStringList) überlegen könnte

[nat]

wenn man es sich ganz einfach (und übersichtlich) machen will, könnte man die dateien
auch in ner eigenen StringList "mitspeichern" und dann halt überMyStringList.Duplicates := dupIgnore; duplikate ignorieren. bei sehr großen dateilisten ist das aber vll nicht unbedingt die optimalste variante
(wegen dem ständigen hin und her kopieren ums in der listbox anzuzeigen) bei ner handvoll einträgen aber sicher
recht kompfortabel und ausreichend!

[trebor90]

Hi!

@quendolineDD:
<< 1.) Wenn die Schleife nicht durchlaufen wird, wird kein Result gesetzt.
2.) Denk mal darüber nach, was passiert, wenn 0 Elemente in der Listbox sind. Smile
3.) Außerdem gab es doch bei Listbox die Funktion .IndexOf[].

Edit:
4.) Dann würde ich lieber eine while- oder repeat-Schleife nehmen, anstatt mit einem break zu arbeiten.
5.) Und das false kannst du ja schon ganz am Anfang setzen und nur noch bei einem Fund den Rückgabewert auf true ändern.
>>

Tut mir Leid, dass ich deinen Beitrag so zerpflücken und abändern muss, aber ich habe ansonsten keine Chance, darauf geregelt zu antworten ...:
1.) Warum sollte die Schleife nicht durchlaufen werden? Sie wir immer durchlaufen. (Die Funktion wird nicht nur einmal bei Drag'n'Drop ausgeführt, sondern für jede einzelne Datei).

Delphi-Quellcode:

//Fügt Datei aus Listbox4 hinzu, wenn Schonda=false also Datei noch nicht da; prüft jede einzelne Datei mit jedem einzelnen Element
for r:=1 to (listbox1.items.count) do
  if schonda(listbox4.items[r-1])=false then
    listbox1.items.add(listbox4.items[r-1]);

2.) Was ist daran so schlimm, wenn 0 Elemente vorhanden sind? Dann durchläuft er die Schleife nicht. Und das ist ja nicht schlimm. Sind ja eh keine Elemente da ...
3.) Ob ich nun (s=listbox1.items[i-1]) oder (listbox1.items.indexof[...]=listbox1.items[i-1]) ist doch egal ...
4.) Ist doch egal ob ich breake oder ob ich mit einer geregelten Bedingung eine andere Wiederholungsstruktur verlasse ...
5.) Das false brauche ich nicht zu setzen, da boolesche Variablen etc. nicht initialisert werden müssen; sie haben als Startwert immer false ...

Mir geht es auch weniger darum, möglichst wenig Rechenaufwand oder so einzubringen oder Die Funktion mitb anderen Befehlen schöner aussehen zu lassen ... Ich sehe das "Loch" in meiner Funktion nicht. Wenn mein Result=undefiniert sein kann, dann muss es also einen Programmierpfad geben, indem Result nicht klar definiert wird, sich also der Startwert nicht ändert. Und das verstehe ich nicht. Durch mein If-Else sage ich doch genau, entweder so oder so. Ich sage doch in einer bestimmten Bedingung nicht nichts ... Versteht ihr mich?!


Gruß - RObert

[jfheins]

Wenn die obere Grenze der Schleife kleiner ist als die untere Grenze wird die Schleife nicht durchlaufen. Falls also keine Elemente in der Listbox sind (was theoretisch ja passieren könnte) wird die Schleife nicht durchlaufen und damit das if-Statement ebensowenig.

Also eher so:

Delphi-Quellcode:

function TForm1.schonda(s:string):boolean; 
var i,a:integer; 
begin 
result:=false; 
a:=listbox1.items.count; 
for i:=1 to a do 
  if (s=listbox1.items[i-1]) then 
    begin 
      result:=true; 
      break; 
    end 
end;

[Satty67]

Wenn die Liste leer ist, dann ist a = 0. Bei a = 0 wird die Schleife nicht durchlaufen und somit auch Result nie ein Wert von Deinem Code zugewiesen. In dem Fall gibt Result den Wert zurück, mit dem Delphi die Variable initialisiert hat.

Das hier ein Wert zurückgegeben wird, den Delphi entschieden hat und nicht Dein Code, davor wirst Du gewarnt.

Wie gesagt, Delphi weis nicht, ob die Liste nie leer sein kann. Delphi weis auch nicht, ob es OK ist, das Result = False bei leerer Liste.

PS: Ist es überhaupt garantiert, das Boolean immer mit False initialisiert werden?

[nat]

zu 3) ich glaub quendolineDD meinte, dass du dir die ganze funktion durch einen aufruf von indexof sparen könntest
vorhanden := Listbox1.Items.IndexOf(Filename) >= 0;