Eine Möglichkeit wäre, dass die Einträge in den ListBoxen bereits Zeilenumbrüche beinhalten. Wie kommen die Werte denn in die ListBox?
Kopier mal den folgenden Code an die Stelle Deines Codeschnipsels und poste dann hier das Ergebnis:


Nebenbei:
Keine Strings in die File-Listbox!
Visual Studio - Empfohlene Einstellungen

Gilt das jetzt für ListBox1 oder ListBox2? (Aussagekräftigere Namen wären hier auch hilfreich.)
Hast Du tatsächlich nur einen Eintrag in der ListBox?
Bist Du sicher, dass diese Einträge nur aus den Zeichen "1", "2" und "3" bestehen sollen? [1]
Du hast auch meine Frage bezüglich der Herkunft der Einträge nicht beantwortet.



[1] Edit:
Ich sehe gerade, dass man das falsch verstehen kann. Das Zeichen "1" hat den Wert 0x31, "2" den Wert 0x32 und "3" den Wert 0x33.
Der Eintrag in der ListBox wäre hier also "232211111111113".
Die Repräsentation, die mein Code ausspuckt, besteht zufälligerweise auch nur aus diesen drei Zeichen (und Bindestrichen). Das ist aber Zufall. Also nicht verwechseln.

Mal so am Rande:
Dieser Thread ist mit VB.Net getagt, du verwendest aber VB Code !
Böses aus VB6/VB2003 - und die richtigen VB.NET-Alternativen
Visual Studio - Empfohlene Einstellungen

Toni03 schrieb:

Sie werden entweder aus der Datei ausgelesen oder durch zwei Textboxen hinzugefügt.

Naja, aber wie genau?
(Ich würde hier erwarten, dass Du den entsprechenden Code postest.)

Der Teufel steckt im Detail. Du musst unbedingt auf die Details achten!

Toni03 schrieb:

​32-33-32-32-31-31-31-31-31-31-31-31-31-31-3341-70-70-6C-65

Mein Code kann gar nie solchen Text erzeugen. Irgendwas muss beim Einfügen danebengegangen sein.

Toni03 schrieb:

Ich hatte es einmal mit der einen Listbox und einmal mit der anderen Listbox probiert.

Ja welche? Ich brauche den Text für ListBox1 und ich brauche den Text für ListBox2, damit ich feststellen kann, ob die Zeilenumbrüche aus den ListBoxen kommen, oder von wo anders.

Toni03 schrieb:

Wie meinst du das mit den Zeichen: "1", "2" und "3". Es sind normalerweise ganze Wörter

Mein Code gibt für jeden Eintrag der entsprechenden ListBox eine Zeile aus. Jede Zeile besteht aus durch Bindestrichen getrennte, hexadezimale Zahlen. Jede Zahl stellt ein Zeichen im Eintrag in der ListBox dar. Die Zahl 0x31 (das "0x" am Anfang ist eine weit verbreitete Schreibweise, um auf das Hexadezimalsystem hinzuweisen; man kann z.B. auch &H verwenden) steht für das Zeichen, das als "Ziffer Eins" bekannt ist, und welches so aussieht: 1. 0x32 steht für "Ziffer Zwei", also 2. Und so weiter. Welche Zahl für welches Zeichen steht, sieht man in sogenannten Encoding-Tabellen: pld.ttu.ee/~marek/PA_R4/asciiful.gif
Der Text, den Du in Post #3 gepostet hast, besteht nur aus 0x31, 0x32 und 0x33. Also besteht der Eintrag, den dieser Text repräsentiert, nur aus den Ziffern 1, 2 und 3. "32-33-32-32-31-31-31-31-31-31-31-31-31-31-33" besteht aber auch nur aus 1, 2 und 3. Ich wollte nicht, dass Du das verwechselst.
Und die Frage, ob der Eintrag wirklich nur aus den Zeichen 1, 2 und 3 bestehen sollen, habe ich gestellt, weil es für mich auf den ersten Blick ungewöhnlich aussieht. Deshalb wollte ich, dass Du mir versicherst, dass das Deine Absich ist (oder eben nicht, falls nicht).

Toni03 schrieb:

Apfel
Kirsche
[...]

Nein, ich meinte den Text, den mein Code in die Zwischenablage kopiert.

Aber ich sehe schon das Problem:

Toni03 schrieb:

Für das auslesen aus der Datei
[...]

Mal sehen, ob Du nicht selber drauf kommst, wenn ich Dich in die richtige Richtung schubse.
Diese Richtung wäre Post #2, der Link gaaanz unten. Ich schreib ja nix umsonst

Warum Option Strict On so dringend benötigt wird, ist im ersten Post des verlinkten Threads ausführlich erklärt. Ohne Option Strict On erlernt man nicht den korrekten Umgang mit den Datentypen. Also "Mir bringt Option Strict On nichts" ist schon eine starke Ansage.
Mich würde jetzt interessieren, ob meine Vermutung gestimmt hat. Wo hast Du denn das Problem gefunden? (Es gehört sich übrigens, im Forum immer auch die gefundene/gewählte Lösung zu zeigen, damit andere, die das gleiche Problem haben, hier die Lösung wieder finden können.)

Ich bin immer wieder erstaunt, mit welchen kreativen Lösungen sich Einsteiger trotz Option Strict On durchmogeln. Wobei das in diesem Fall wohl auf die unsinnigen Vorschläge von Visual Studio zurückzuführen sein dürfte. Das sind eher Symptombehandlungen, als richtige Lösungen.
Es bringt jetzt auch nichts, Dir einfach zu sagen, dass die bei Dir aufgerufene Überladung der String.Split-Funktion aus dem String "Hallo" & vbCrLf & "Welt" nicht das Array {"Hallo", "Welt"} macht, sondern {"Hallo", "", "Welt"}. Es wird nämlich einmal am CR-Zeichen gesplittet und einmal am LF-Zeichen. Das dürfte der Grund sein, warum Du im Nachhinein versuchst, irgendwelche leeren Einträge aus der ListBox zu löschen. Aber mit dem On Error Resume Next sind solche Probleme auch nicht zu diagnostizieren.
Versuche zu verstehen:
Du siehst ja, dass am Ende nicht das richtige Ergebnis rauskommt. Warum passiert das? Na vermutlich aufgrund eines Fehlers im Code. Aber Du schreibst ja noch hin, dass bei einem Fehler einfach blind weitergemacht werden soll. Wie sollst Du also jemals herausfinden wollen, wo der Fehler liegt?
Entferne das On Error Resume Next und lass Dir von der IDE zeigen, wo es Probleme gibt. Wannimmer Dein Programm etwas Unerwartetes macht, stell Dir die Frage: Warum?
Versuche nicht, das unerwartete Verhalten zu kaschieren, sondern versuche, den Grund für das Verhalten zu finden. Die leeren Einträge erscheinen nicht aus Jux und Tollerei in der ListBox, sondern dafür gibt es einen guten Grund. Der Debugger hilft Dir übrigens, die Funktionsweise Deines Codes besser nachzuvollziehen: Debuggen, Fehler finden und beseitigen
Arbeite Dich schrittweise durch den Code. Schau Dir an, was die Variablen für Werte haben. Irgendwann stößt Du zu einer Zeile vor, die nicht das macht, was Du erwartest.

@Toni03 Warum nicht einfach so: