Suchergebnisse

Es stehen immer die gleichen Einträge in ListBox1 und 2. Denn Du löschst alle Einträge (Zeile#19, #26) und fügst alle Dateinamen hinzu. Bevor Du weitermachst, bitte die empfohlenen VS-Einstellungen verwenden. Stichwort UBound. Das Hinzufügen geht auch einfacher: ListBox1.Items.AddRange(arroFilesalt). Und kümmer Dich am besten zeitnah um gute Benennung. ListBox1? arroFilesneu?

Argh. Denkfehler. Das Problem ist, dass Du mit Objekten (in dem Fall von Typ IO.FileInfo) arbeitest. Zwei FileInfo-Objekte, die auf dieselbe Datei verweisen, sind nicht identisch, werden also nicht von Contains mit True erkannt. Daher darfst Du nicht die Objekte vergleichen, sondern z.B. FullPath, also den kompletten Dateipfad. Wird nur vom Coden her komplizierter: VB.NET-Quellcode (6 Zeilen) ach ja: Next i geht auch mit Next ohne i

Puh … und dann bitte gleich noch Option Strict On, ganz wichtig! Nein, AddRange geht so nicht mehr. Da Du fügst ja nun einen Teil von arroFilesneu (nämlich den Dateinamen) hinzu. Das ginge mit Deiner For-Loop oder eben wieder mit LINQ:VB.NET-Quellcode (1 Zeile) Aber: Keine Strings in die File-ListBox!

Deshalb der Hinweis bezüglich des Threads empfohlene VisualStudio-Einstellungen; anklicken, durchlesen, beherzigen, anwenden. LINQ: Ja, Select wählt quasi für alle Elemente einer Ansammlung eine gemeinsame Eigenschaft und gibt dieses als aufzählbare Ansammlung (IEnumerable(Of WasAuchImmer)) zurück. So wird z.B. aus einem FileInfo-Array mittels Select ein IEnumerable(Of String), welches die Namen der Dateien enthält. Man kann das Ganze noch in ein Array umwandeln, falls man der Meinung ist, dass …

Sorry, wenn es so rüberkam, aber wir tendieren selten dazu, jemanden zu verulken. Da heute schon ein anderer User das Gefühl hatte, muss aber wohl was dran sein. Nur leider kann man den Tonfall nicht schreiben. Ich hatte das Thema ins Spiel gebracht, weil ich das Gefühl hatte, dass es bei Dir ausgeschaltet ist. Die Option lässt einen Fehler zur Codingzeit sehen, die sonst erst zur Laufzeit auftauchen. Wenn bei Dir alles ohne geht, sehr gut. Option Strict auf On schalten und VB6-Namespace raus si…

Vorteil von Option Strict Off ist, dass der Compiler versucht Dir Dinge abzunehmen, um die Du Dir gedanken machen solltest, in erster Linie (aber nicht nur!): die korrekte Verwendung (und Umwandlung) von Datentypen (ineinander). Spätestens wenn Datentypen inkompatibel sind, scheitert der Compiler zur Laufzeit bei Off. Bei On kompiliert das Programm erst gar nicht, sondern VS weist den Programmierer sofort darauf hin, dass da was nicht stimmt.

1. Mag sein, dass beide den Wert 1 haben, aber das ist mit Absicht. Typsicherheit, AFAIK. 2. Deine Split-Methode ist VB6. Hinfort damit!

Dim DeineTextTeile = "DeinText|mit Trennern".Split("|"c) siehe auch Böses aus VB6/VB2003 - und die richtigen VB.NET-Alternativen

Ja gut. Man sollte natürlich schon wissen, welcher Datentyp bei einer Funktion rauskommt, wenn man Option Infer On stellt. Also nicht nur String oder String-Array, sondern eben auch Integer, String, Foo, … Solange man da nicht sicher ist oder noch nicht weiß, wie man das schnell rausfindet (Maus über die Variable und VS zeigt's), sollte man Option Infer wohl besser ausschalten.