Listboxen vergleichen

[Paulh]

Hallo,

ich sitze in letzter Zeit an einem Program, dass Backup löschen soll, es soll immer ein Backup pro Tag behalten werden.
Das sortieren klappt so weit, heisst ich weiss welche Backups ich behalten will, dafür habe ich zwei Listboxen, eine
die die zubehaltenden Backups anzeigt[Listbox1] und eine die alle Backups anzeigt[Listbox2].

Das Problem besteht darin, dass ich es nicht hin bekomme heraus zufinden welches Backup jetzt gelöscht werden soll oder
nicht. Hier ist der Code den ich dafür vorgesehen hatte:

Delphi-Quellcode:

for I := 0 to Listbox2.Items.Count-1 do
begin
  for Ia := 0 to Listbox1.Items.Count-1 do
    begin

      if NOT (Listbox2.Items[i]=Listbox1.Items[ia]) then
      begin
           //Die sollen gelöscht werden
      end;
    end;
end;

Vielen Dankt im vorraus !

[Captnemo]

Versuchs doch mal mit Listbox1.Items.IndexOf(Listbox2.Items[i])

Result ist gleich der Index des gesuchten Elements, oder, wenn es diese nicht gibt, -1

Das hilft dir bestimmt weiter.

[Paulh]

Meinst du so ?

Delphi-Quellcode:

if NOT (Listbox1.Items.IndexOf(Listbox2.Items[i])=-1) then

[Captnemo]

Oder mit ein bischen Quelltext:

Delphi-Quellcode:

for i := Listbox1.items.count-1 downto 0 do begin
  if Listbox2.items.indexof(Listbox1.items[i])=-1 then begin
    if DeleteFile(Listbox1.items[i]) then
      Listbox1.delete(i);
  end;
end;

Hier gehe ich die Listbox1 von unten nach oben durch. Wenn das jeweilige Element in der Listbox2 nicht vorhanden ist, dann wird das Backup gelöscht. Ist das Löschen erfolgreich, wird das Element aus Listbox1 auch auch gleich entfernt.

[Captnemo]

Zitat:

Zitat von Paulh (Beitrag 1184993)

Meinst du so ?

Delphi-Quellcode:

if NOT (Listbox1.Items.IndexOf(Listbox2.Items[i])=-1) then

Ich hätte jetzt geschieben:

Delphi-Quellcode:

if Listbox1.items.IndexOf(Listbox2.Items[i])>-1 then

ist aber im Grunde das gleiche. Möglicherweise ist der verzicht auf NOT etwas schnellen, aber das wird ggf. auch vom Compiler optimiert, wäre aber auch bei dieser Operation zu vernachlässigen, da die Rechner heute so schnell sind, dass das eh nicht auffallen würde. (Meine Meinung ;-) )

[Captnemo]

Zitat:

Zitat von Captnemo (Beitrag 1184994)

Oder mit ein bischen Quelltext:

Delphi-Quellcode:

for i := Listbox1.items.count-1 downto 0 do begin
  if Listbox2.items.indexof(Listbox1.items[i])=-1 then begin
    if DeleteFile(Listbox1.items[i]) then
      Listbox1.delete(i);
  end;
end;

Hier gehe ich die Listbox1 von unten nach oben durch. Wenn das jeweilige Element in der Listbox2 nicht vorhanden ist, dann wird das Backup gelöscht. Ist das Löschen erfolgreich, wird das Element aus Listbox1 auch auch gleich entfernt.

Achso, noch eine kleine Ergänzung:

das "downto" würde ich diese Stelle verwenden, weil wenn du es anders herum macht, also "for i:=0 to Listbox1.items.count-1" dann kommst du ja irgendwann an eine Stelle, wo aus Listbox1 ein Element löscht. Nach dem Löschen ist Listbox1.Items.count ja kleiner, und die Schleife will am Ende irgendwann auf ein Element zugreifen, was ja gar nicht mehr existiert. Dann hagelt es eine Exception.

[sx2008]

Du kannst das Problem reduzieren, indem du nicht die Listboxen anschaust sondern die Items[] Properties.
Dabei handelt es sich um TStrings-Objekte. (bzw. von der Klasse TStrings abgeleitet).

Also willst du zwei Stringlisten "vergleichen".
Vergleichen ist auch nicht das richtige Wort, sondern es dreht sich eher um Mengenlehre.
Man kann die Schnittmenge zweier Stringlisten bilden oder die Vereinigungsmenge oder auch die Restmenge (Menge A ohne B).

siehe auch Code-Library: http://www.delphipraxis.net/20262-me...inglisten.html

Wenn man mal das Prinzip der Mengenlehre begriffen hat, dann braucht man nicht im Nebel stochern sondern kann gezielt das Richtige tun.
Und somit hoffe ich, dass alle die hier schnell aus der Hüfte mit etwas Code geschossen haben noch etwas dazulernen.

[Paulh]

Habe es jetzt mit einer 3. Listbox versucht und es kommt aber immer noch ein mischmasch raus :(

Delphi-Quellcode:

for i := Listbox1.items.count-1 downto 0 do begin
  if NOT (Listbox2.items.indexof(Listbox1.items[i])=-1) then begin
    //if DeleteFile(Listbox1.items[i]) then
      Listbox3.Items.Add(Listbox2.Items[i]);
  end;
end;

[Captnemo]

Zitat:

Du kannst das Problem reduzieren, indem du nicht die Listboxen anschaust sondern die Items[] Properties.
Dabei handelt es sich um TStrings-Objekte. (bzw. von der Klasse TStrings abgeleitet).

Also willst du zwei Stringlisten "vergleichen".
Vergleichen ist auch nicht das richtige Wort, sondern es dreht sich eher um Mengenlehre.
Man kann die Schnittmenge zweier Stringlisten bilden oder die Vereinigungsmenge oder auch die Restmenge (Menge A ohne B).

siehe auch Code-Library: Mengenoperationen mit Stringlisten

Wenn man mal das Prinzip der Mengenlehre begriffen hat, dann braucht man nicht im Nebel stochern sondern kann gezielt das Richtige tun.
Und somit hoffe ich, dass alle die hier schnell aus der Hüfte mit etwas Code geschossen haben noch etwas dazulernen.

Und was ist jetzt daran einfacher?

[Popov]

Zitat:

Zitat von Captnemo (Beitrag 1184999)

das "downto" würde ich diese Stelle verwenden, weil ...

Auch wenn es die Höflichkeit gebietet in der Kommunikation immer die Ich-Form zu wählen um den Gegenüber nicht vor den Kopf zu stoßen, wie z. B. "würde ich", ändert es nichts daran, dass hier ein "musst du" angebracht ist, denn es gibt nur die eine Variante. Alles andere führt zum Knall ;)

[Captnemo]

Zitat:

Zitat von Popov (Beitrag 1185005)

Zitat:

Zitat von Captnemo (Beitrag 1184999)

das "downto" würde ich diese Stelle verwenden, weil ...

Auch wenn es die Höflichkeit gebietet in der Kommunikation immer die Ich-Form zu wählen um den Gegenüber nicht vor den Kopf zu stoßen, wie z. B. "würde ich", ändert es nichts daran, dass hier ein "musst du" angebracht ist, denn es gibt nur die eine Variante. Alles andere führt zum Knall ;)

Naja, rein theoretisch kann er ja auch die Items erst einmal in einer weiter StringList speichern, um später damit zu arbeiten, und die Elemente in den ListBoxen noch so lassen. In dem Fall wäre es egal. Ich habe das ganze halt nur der Form halber erläutert.

[Popov]

... kleiner Fehler. Code mal kurz entfernt...

@Captnemo

War ja keine Kritik.

[Captnemo]

Zitat:

Zitat von Paulh (Beitrag 1185003)

Habe es jetzt mit einer 3. Listbox versucht und es kommt aber immer noch ein mischmasch raus :(

Delphi-Quellcode:

for i := Listbox1.items.count-1 downto 0 do begin
  if NOT (Listbox2.items.indexof(Listbox1.items[i])=-1) then begin
    //if DeleteFile(Listbox1.items[i]) then
      Listbox3.Items.Add(Listbox2.Items[i]);
  end;
end;

Was kommt den raus?
Normalerweise müssten jetzt in listbox3 alle Elemente auftauchen, die sowohl in Listbox1 als auch in Listbox2 sind.
Denk aber daran, dass auch groß und kleinschreibung unterschieden wird. Ggf. noch ein lowercase() einbauen.

[Paulh]

Ich grübe grade darüber nach was ich von den 3 Mengenoperationen verwenden muss, aber ich denke,
wenn ich

Delphi-Quellcode:

DifferenceStrings(Listbox2.Items,Listbox1.Items,Listbox3.Items)

nehmen würde müsste es doch gehen oder ?

[Captnemo]

Zitat:

Zitat von Popov (Beitrag 1185009)

Delphi-Quellcode:

for i := Listbox1.items.count-1 downto 0 do 
begin

  if Listbox2.items.indexof(Listbox1.items[i]) = -1 then 
    Listbox2.Items.Delete(i);

end;

Genau hier ist ja das downto nicht zwingend notwendig, weil du die Elemente ja nicht in ListBox1 löscht. ;-)

Okay, aber am ende kommt ja alles auf das gleiche raus.

[Paulh]

Okey jetzt gehts, O.o komisch...

Aber danke an alle !
..war schon wieder am verzweifeln..

[Captnemo]

Zitat:

Zitat von Paulh (Beitrag 1185011)

Ich grübe grade darüber nach was ich von den 3 Mengenoperationen verwenden muss, aber ich denke,
wenn ich

Delphi-Quellcode:

DifferenceStrings(Listbox2.Items,Listbox1.Items,Listbox3.Items)

nehmen würde müsste es doch gehen oder ?

Also ganz ehrlich. Ich würde an deiner Stelle jetzt nicht den Code aus DifferenceStrings kopieren.

Die von dir gestellt Aufgabe ist so einfach, dass du dir selbst einen Gefallen tust, wenn diesen zweizeiler selber entwirfst, und am ende auch verstehst, wo wie ich und popov es dir vorgeschlagen haben.

[Paulh]

Ja,okey habe aber auch schon lange nichts mehr mit Delphi gemacht...

Habs jetzt auch so hin bekommen.

[Captnemo]

Ja, manchmal beißt man sich an einfachsten Sachen fest. Kein Problem.

[sx2008]

Zitat:

Zitat von Captnemo (Beitrag 1185004)

Und was ist jetzt daran einfacher?

Man braucht nur eine Prozedur (getestet und wiederverwendbar) aufrufen anstatt unschönen Code einzubauen.
Mit "unschön" meine ich jetzt z.B. das fehlende BeginUpdate/EndUpdate.
Unschön ist natürlich auch keine Unter-Funktion/Prozedure zu verwenden.

[Captnemo]

Zitat:

Zitat von sx2008 (Beitrag 1185021)

Zitat:

Zitat von Captnemo (Beitrag 1185004)

Und was ist jetzt daran einfacher?

Man braucht nur eine Prozedur (getestet und wiederverwendbar) aufrufen anstatt unschönen Code einzubauen.
Mit "unschön" meine ich jetzt z.B. das fehlende BeginUpdate/EndUpdate.
Unschön ist natürlich auch keine Unter-Funktion/Prozedure zu verwenden.

Das kommt jetzt mal ein bischen darauf an, in welcher Form man das verwenden will.

Wenn ich tatsächlich nur aus einer Liste alle in einer zweiten Liste vorhanden Elemente löschen will,
dann reicht mir ja im Grund ein Zweizeiler.

Delphi-Quellcode:

  for i:=listbox1.items.count-1 downto 0 do
    if listbox2.items.indexof(listbox1.Items[i])>-1 then
       Listbox1.items.delete(i);

Gut, jetzt sind's 3 Zeilen ;-)

Diese jetzt doch relativ simple Aktion extra noch in eine Funktion zu packen, die dann wiederum
eine weitere StringListe benötigt, um dann am Ende das gleich zu erhalten, was hinterher in Listbox2 stehen sollte,
halte ich für unsinnig.
Zum einen wird der Code dadurch nicht unbedingt überichtlicher, und zum zweite muß ich hinterher dann auch noch die
Listbox2 neu aufbauen.
Außerdem kann ich so die auszuführenden Aktionen auch gleich mit in die Schliefe packen.

Die einzigen Gründe, die mir dazu einfallen würden, wären:

1. Ich will die Listboxen erst verändern, wenn ich alle Aktionen, die das Ergebnis betreffen, ausgeführt wurden
2. Ich will die Differenz noch mehrmals verwenden.
3. Ich will dem Benutzer erst eine Liste aller betroffenen Elemente als Vorschau anzeigen.

Aus deiner ursprünglichen Frage schließe ich aber, dass du lediglich die Differenzelemente aus der Liste löschen und die backups löschen willst. Dafür würde ich mir nicht erst eine Funktion anlegen, weil ich die ja nur einmal benötige, und ich dadurch an dieser Stelle noch nicht einmal Code gespart habe.
Denn: Ich muß mir extra noch ein StringList anlegen, ich muß natürlich die Funktion aufrufen, ich muß hinterher meine neue Stringlist (wieder mit einer Schliefe) verarbeiten, und ich muß die Listbox1 trotzdem aktualisieren. Und den zusätzlich code für
die Funktion brauch ich auch noch.

also habe ich durch die Funktion min. 10-15 Zeilen mehr Code.

Bei aufwendigeren Funktionen macht das aber durchaus sinn, oder wenn es der Übersichtlichkeit dient.

[sx2008]

@Captnemo: irgendwie fällt es dir schwer die Listboxen loszulassen und nur in Listen zu denken.
Man kann Liste B von A abziehen indem man das Ergebnis in C schreibt oder man macht es so wie du quasi in-place:

Delphi-Quellcode:

// Berechne A=A-B
procedure SubstractStringsInplace(A,B:TStrings);
var 
  i:Integer;
begin
  for i:=A.Count-1 downto 0 do
    if B.IndexOf(A[i])>=0 then
       A.delete(i);
end;
...
SubstractStringsInplace(Listbox1.Items, Listbox2.Items);

Und selbst wenn diese Procedure nur ein Einziges mal benützt wird, ist das Ergebnis doch besser lesbar und sogar schneller.
Schneller deswegen weil man nicht ständig auf die Listboxen zugreift, sondern mit den Items, also den TStrings-Objekten arbeitet.
Noch schneller würde es wenn man zusätzlich A.BeginUpdate & A.EndUpdate verwendet.

Auch kleine Funktionen/Proceduren sind wichtig und wertvoll!!

[Captnemo]

Zitat:

Zitat von sx2008 (Beitrag 1185035)

@Captnemo: irgendwie fällt es dir schwer die Listboxen loszulassen und nur in Listen zu denken.
Man kann Liste B von A abziehen indem man das Ergebnis in C schreibt oder man macht es so wie du quasi in-place:

Delphi-Quellcode:

// Berechne A=A-B
procedure SubstractStringsInplace(A,B:TStrings);
var 
  i:Integer;
begin
  for i:=A.Count-1 downto 0 do
    if B.IndexOf(A[i])>=0 then
       A.delete(i);
end;
...
SubstractStringsInplace(Listbox1.Items, Listbox2.Items);

Und selbst wenn diese Procedure nur ein Einziges mal benützt wird, ist das Ergebnis doch besser lesbar und sogar schneller.
Schneller deswegen weil man nicht ständig auf die Listboxen zugreift, sondern mit den Items, also den TStrings-Objekten arbeitet.
Noch schneller würde es wenn man zusätzlich A.BeginUpdate & A.EndUpdate verwendet.

Auch kleine Funktionen/Proceduren sind wichtig und wertvoll!!

Hat mit loslassen nix zu tun.

Mal ehrlich, wenn ich von 10 Backups nur 3 Behalten will, wieviele Millisekunden willst du da durch irgendwelche Funktionen sparen?

Besser lesbar.....sehe ich anders. Wenn überhaupt, dann genauso lesbar. Wir reden hier von 3-5 zeilen code. Was bitte soll denn da unübersichtlich sein?

Und was ist Listbox1.Items....TString-Objekte. Ergo wird der Zugriff auf diese nicht schneller oder langsamer sein, als selbst erzeugte.
Hilfeauszug:

Zitat:

Enthält die Strings, die im Listenfeld angezeigt werden.

Mit Items können Sie Einträge anhängen, einfügen, löschen und verschieben. Standardmäßig sind alle Einträge eines Listenfeldes TStrings-Objekte. Mit den Methoden und Eigenschaften dieser Klasse können Sie die Einträge der Liste bearbeiten.

Wie ich bereits sagte, "In-Place" spare ich mir Code und zusätzliche TSTrings. Meine Meinung.

Wegen mir kann jeder seine kleinen Schliefen in Funktionen auslagern, wenn er das toll findet. Aber mit Übersichtlichkeit hat das in diesem Fall nun wirklich nichts zu tun. Eher im Gegenteil. Wenn ich jede Kleinigkeit in Funktionen auslagere, dann hab ne Unit mit hundeten Funktionen, die alle nur 3-5 Zeilen lang sind. Da steigt ja dann keiner mehr durch.
Damit meine ich jetzt nicht, Spagetti-code zu programmieren. Funktionen ja, aber nur wenn's sinn macht. Besser ist es, vernüftige Kommentare zu setzen.

[Sir Rufo]

@Captnemo
Ich würde dir mal einen Blick auf die Pattern empfehlen, da kann man eine Menge lernen wie und warum ;)
Facade

[Captnemo]

Zitat:

Zitat von Sir Rufo (Beitrag 1185080)

@Captnemo
Ich würde dir mal einen Blick auf die Pattern empfehlen, da kann man eine Menge lernen wie und warum ;)
Facade

Okay, und nun? Klär mich auf ;-)

Genau das sag ich ja. Wenn man einen bestimmten Ablauf an verschieden Stellen benötigt mach es ja sinn, das ganze in eine Funktion zu packen. Mach ich auch nciht anders. Und wenn möglicherweise aufwendige Abläufe nötig sind, versuche ich das auch in ein Funktion zu packen, damit die Übersichtlichkeit gegeben bleibt.

Aber weder das eine, noch das andere ist hier ja gegeben.

Natürlich kann mal letztlich alles vereinheitlichen und in Funktionen realisieren. Nur war das nicht die Frage des Threads.
Er wollte wissen, wie er bei zwei Listboxen zu seinem Ergebnis kommt, und das habe ich ihm gesagt.

Ob er dieses Wissen nun nimmt, um damit das gleiche über TStrings in einer Funktion zu machen, ist ja ihm überlassen. Die prinzipielle Vorgehenweise ist dabei ja letztlich das gleiche.

[sx2008]

Zitat:

Zitat von Captnemo (Beitrag 1185041)

Wie ich bereits sagte, "In-Place" spare ich mir Code und zusätzliche TSTrings. Meine Meinung.

Wegen mir kann jeder seine kleinen Schliefen in Funktionen auslagern, wenn er das toll findet. Aber mit Übersichtlichkeit hat das in diesem Fall nun wirklich nichts zu tun. Eher im Gegenteil. Wenn ich jede Kleinigkeit in Funktionen auslagere, dann hab ne Unit mit hundeten Funktionen, die alle nur 3-5 Zeilen lang sind. Da steigt ja dann keiner mehr durch.
Damit meine ich jetzt nicht, Spagetti-code zu programmieren. Funktionen ja, aber nur wenn's sinn macht. Besser ist es, vernüftige Kommentare zu setzen.

Was soll ich sagen: hoffnungslos. :?


Ich zitiere mal aus dem Buch Clean Code: A Handbook of Agile Software Craftsmanship von Robert C. Martin et al.

Zitat:

The first rule of functions is that they should be small.
The second rule of functions is that they should be smaller than that.

FUNCTIONS SHOULD DO ONE THING. THEY SHOULD DO IT WELL.
THEY SHOULD DO IT ONLY.

In order to make sure our functions are doing “one thing,” we need to make sure that the
statements within our function are all at the same level of abstraction.

Ich kann dir nur empfehlen, das Buch mal zu lesen, falls du wirklich Interesse am Programieren hast.

[Captnemo]

Zitat:

Zitat von sx2008 (Beitrag 1185109)

Ich kann dir nur empfehlen, das Buch mal zu lesen, falls du wirklich Interesse am Programieren hast.

Alles klar

[Furtbichler]

Zitat:

Zitat von Captnemo (Beitrag 1185041)

Wegen mir kann jeder seine kleinen Schliefen in Funktionen auslagern, wenn er das toll findet. Aber mit Übersichtlichkeit hat das in diesem Fall nun wirklich nichts zu tun. Eher im Gegenteil. Wenn ich jede Kleinigkeit in Funktionen auslagere, dann hab ne Unit mit hundeten Funktionen, die alle nur 3-5 Zeilen lang sind. Da steigt ja dann keiner mehr durch.

Du liest nicht die hundert Funktionen, sondern den Code, der sie verwendet. Das die Funktionsnamen selbsterklärend sind, weißt Du, was sie macht und musst nicht die 3-5 Zeiler (oh doch, manchmal auch 7) verstehen. Das spart pro Funktion ein paar Sekunden.

Zitat:

Besser ist es, vernüftige Kommentare zu setzen.

Falsch. Kommentare sind Stil der 80er Jahre. Guter Code benötigt keine Kommentare (Ausnahme: Rechtliche Hinweise und Quellenangaben). Guter Code ist selbsterklärend und liest sich wie ein Buch.

Man muss diese Empfehlungen natürlich aus der Sicht eines professionellen Softwareentwicklers sehen. Der Hobbyprogrammierer versteht nicht, weshalb es besser ist, hunderte kleine Funktionen zu haben, als kommentierten Code, der ohne sie auskommt: Es geht um Lesbarkeit. Ist ein Code lesbar (und kann ich ihn meinem Kollegen vorlesen bzw. er den Code selber lesen), dann ist er verständlich. Und zwar ohne Rücksprache oder das im Code Kommentare verstreut sind. Lesbarer Code ist einfach (KISS). Einfacher Code ist robust und erweiterbar.

[Captnemo]

Auch ich arbeite mit Funktion.

Die Frage des Threaderstellers war es, wie er zwei Listbox so vergleichen kann, dass er sein gewünschtes Ergibnis erhält.

Ich habe ihm eine Antwort gegeben, die ihm bei der Lösung seines Problems hilft. Punkt.

Ich halte nichts davon, jemandem dann eine Unit rein zu kopieren, die ihm Funktionen für ein so simples Problem zur Verfügung stellt, die dann ohne eigenes Zutun das gewünschte Resultat bring, ohne verstehen zu müssen, was da eigentlich passiert. Einfach reinkopieren und fertig.

Das das keiner Verstehen will....okay. Deswegen lass ich mich hier nicht als "hoffnungslos" betiteln.
Jedenfalls hab ich jetzt keine Bock mehr hier jemandem einen Lösungsvorschlg zu posten. Damit ist dieser Thread für mich erledigt.

[himitsu]

PS: Die Konstante -1 ergibt meistens soeinen unschönen Assemblercode und der Vergleich darauf ist auch nicht so schön.

Wenn man anstatt mit dem "Fehler" zu vergleichen, auf die korrekten Werte prüft, sieht es gleich viel hübscher aus.

z.B. bezüglich

Delphi-Quellcode:

if IndexOf(...) = -1 then

oder

Delphi-Quellcode:

if not (IndexOf(...) = -1) then

:

Delphi-Quellcode:

if IndexOf(...) < 0 then

für "ist nicht drin" (OK, es sei denn man hat eine "sprechende" Konstante für den Fehlercode)
und

Delphi-Quellcode:

if IndexOf(...) >= 0 then

für "ist drin".

Eine positive Logik klingt auch meistens freundlicher und wenn man sich durchgehend vorwiegend auf eine Logik bezieht, ist der Code IMHO oftmals auch schneller verständlicher, da man weniger überlegen muß.