So gehts:Ich habe die Dateinamen in ein Array getan - _Filenames(), und die Controls auch.
IN der Schleife wird jedem Control ein Filename zugeordnet - vorher mit dem Basispfad kombiniert.

Kein TryCatch!
Lässt sich eine der Dateien nicht laden, soll die Exception kommen.
Denn dann hat das Prog einen Fehler, der behoben werden soll, anstatt den User mit einer Messagebox allein zu lassen.
Es können zig verschiedene Fehler auftreten - nicht nur, dass die Datei fehlt.
TryCatch ist ein heißes Eisen

edit:
@ Visual_Prog
Die Testanwendung funktioniert einwandfrei.
In welcher Zeile tritt der Fehler auf ?

ErfinderDesRades schrieb:

Lässt sich eine der Dateien nicht laden, soll die Exception kommen.
Denn dann hat das Prog einen Fehler, der behoben werden soll, anstatt den User mit einer Messagebox allein zu lassen.
Es können zig verschiedene Fehler auftreten - nicht nur, dass die Datei fehlt.

Manchmal ist es aber sinnvoll, dem Anwender eine Möglichkeit zu geben, zu reagieren.
Also z.B., wenn eine config Datei nicht existiert, beschädigt ist, oder Leserechte Fehlen.
Wenn eine Date fehlt, kann man z.B. eine FileOpenDialog anbieten, oder fragen ob eine Standarddatei erzeugt werden soll.
Dafür ist File.Exist() doch da.
Ich finde eine gezielte Verwendung, auch von Try Catch ist durchaus angesagt und im Idealfall bekommt der Anwender nie eine, nicht extra für ihn aufbereite, Fehlermeldung.

Visual_Prog schrieb:

wie kann man die textboxen leeren, wenn die zugehörige datei nicht existiert?

Du checkst die Existenz der Datei. Wenn sie nicht vorhanden ist, löschst Du die Textbox und verlässt die Prozedur:

@Visual_Prog Überzeuge Dich davon, dass Dein Array _FileNames das enthält, was Du glaubst dass es enthält.
Besser wäre da ne For-Schleife.
Wenn Dein NUD als Minimum Null hat, brauchst Du den Fall < 0 nicht abzutesten. Wenn Du das Maximum auf den entsprechenden Wert setzt, brauchst Du auch die obere Grenze nicht zu testen.
Gib dem Array, das Deine "Karteikarten" enthält, den korrekten Typ.
Mega-oft musst Du nix schreiben, wenn Du eine entsprechende Boolean Prozedur machst, der Du den Index übergibst.

Pasta schrieb:

Ich finde eine gezielte Verwendung, auch von Try Catch ist durchaus angesagt und im Idealfall bekommt der Anwender nie eine, nicht extra für ihn aufbereite, Fehlermeldung.

Indem du das sagst (wobei völlig offen ist, was "gezielt" ist), ermutigst du ihn, wieder solche Super-Gurken hinzuhauen, und zu meinen, er täte damit Zeit sparen:

Visual_Prog schrieb:

VB.NET-Quellcode

1. Try
2. _Controls(ii).Text = File.ReadAllText(_BasePath & _FileNames(i + ii))
3. Catch ex As Exception
4. End Try

Das Gegenteil ist der Fall - diese Gurke kostet immens Zeit.
Wie gesagt: Königsweg ist so zu programmieren, dass absehbare Exceptions garnet erst auftreten. (Dann treten allenfalls noch unabsehbare Exceptions auf, und die sollen das Prog beenden, weil es eben nicht richtig funktioniert)
Falls eine der Dateien nicht existiert, sollte die entsprechende Auswahlmöglichkeit von vornherein erstmal garnet präsentiert werden.
(Dafür ist die Auswahl per NUD natürlich ziemlich problematisch)

Aber das muss man im Gesamtzusammenhang der Anwendung sehen, also was sind das für Dateien, wie kann es zustandekommen, dass Dateien fehlen, kann auf diese Dateien verzichtet werden, kann ein User diesen Fehler (dass Dateien fehlen) korrigieren, ... ?

Visual_Prog schrieb:

weil die ja nicht da ist.

Dann musst Du bei der Feststellung, dass keine Datei da ist, die Textbox halt löschen.
Wenn Du im NUD-Changed-Event zunächst alle Textboxen löschst, musst Du bei Datei nicht vorhanden einfach nur nichts tun.

mir sieht das insgesamt sehr danach aus, dass hier Datenverarbeitung neu erfunden wird.
Und statt ein standard-Datenmodell zu implementieren mit Tabellen und Datensätzen wird was ganz komisches im Dateisystem angefangen, mit Dateien, die Karteikarten darstellen sollen und sowas.