Interessant, dass Du soweit gekommen bist. Wenn ich versuche, ein ListView mithilfe eines anderen Threads zu befüllen, erhalte ich das von mir Erwartete:

Visual Studio schrieb:

System.InvalidOperationException: "Ungültiger threadübergreifender Vorgang: Der Zugriff auf das Steuerelement TestListView erfolgte von einem anderen Thread als dem Thread, für den es erstellt wurde."

Hast Du etwa CheckForIllegalCrossThreadCalls = False irgendwo stehen?

Dazu 5 Gedanken - jeder ist substanziell, also achte drauf, dass, wenn du mit einem Gedanken dich auseinandergesetzt hast, dir auch die anneren vorzunehmen.
Meist beschäftigen sich Fragesteller nur mit einem Gedanken, und 5 Posts weiter muss man sie dann drauf hinweisen, dass man das alles bereits in Post#2 beantwortet hat.

1. aus einem NebenThread kann man nicht auf Controls zugreifen - das geht aus technischen Gründen nicht.
2. Sondern man muss den Zugriff per Control.BeginInvoke() an den MainThread zurück-delegieren.
   Controls Threadsicher machen
   Lass dir nix anneres einreden - extrem weit verbreitet ist, Control.Invoke zu empfehlen, was allerdings gegenüber .BeginInvoke ganz unnütz Performance verschenkt.
   
3. Nun wäre es bei MassenOperationen (etwa Befüllung eines ListViews) verheerend, für jedes Item einen Threadwechsel vorzunehmen.
   Daher stellt man in NebenThreads MassenDaten bereit - das Einfügen erfolgt aber summarisch wieder im MainThread
   
4. Ein sehr fortschrittliches Konzept ist Async/Await - das kommt ohne Control.BeginInvoke aus
   
5. Meist ist garkein Threading erforderlich
   Etwa die einfache Anwendung von ListView.BeginUpdate/.EndUpdate kann einen Ladevorgang u.U. um Faktor 1000 beschleunigen.
   

pts schrieb:

wenn das Fensterhandle erstellt wurde

? Wann rufst Du diese nebenläufige Befüllungsroutine denn auf? Bei Erstellung des Formulars?

pts schrieb:

Danke, ich werde mich mal mit dem Thema Invoke auseinandersetzen.
[...]
EDIT: so?

VB.NET-Quellcode

1. Friend Sub AddToList(LVI As ListViewItem)
2. TestListView.Invoke(Sub() TestListView.Items.Add(LVI))
3. End Sub

Damit hast du es fast auf meine Ignorier-Liste geschafft.
Weil meine Posts liest du offsichtlich eh nicht.

Warum nur fast? Anfänger-Bonus.
Allerdings in eim anneren Thread biste mit NoFear ja auch nicht anners umgegangen - also du hast in kürzester Zeit doch beträchtlich Minuspunkte angesammelt - vermutlich ohne zu merken, deshalb sag ichs dir.

pts schrieb:

.BeginInvoke scheint bei mir keine mögliche Methode zu sein (zumindest zeigt IntelliSense die nicht an) Deswegen habe ich .Invoke genommen

Kann nicht sein. Mit Sicherheit funzt dieses ebensogut, und wird auch Intellisense-Unterstützt:Ansonsten muss dein VisualStudio iwie verkorkst sein.

Noch ansonstener freuts mich, dass du dich mit meine Punkte nu erkennbar auseinandersetzt, und ich finde, es bringt auch entsprechend sehr viel: Dir wird mit BeginInvoke geholfen sein, und alle Leser haben ein deutlich klareres Bild der Problemstellung.

---

Zu deiner Frage: Nee, ich find, du machst das alles genau korrekt, und sollte so denn auch funzenieren.
Deine Fehlermeldung aus post#4 bedeutet aber, dass der Thread viel zu schnell fertig ist, nämlich noch ehe das TreeListView richtig initialisiert ist.
Sowas kann auch passieren, wenn TreeListView auf einem TabControl-Tab sitzt, der noch nie angezeigt wurde.
Probierma so:
Wie gesagt: Achte drauf, dass das nicht aufgerufen wird, bevor das Form angezeigt ist (Handle erstellt)

Oder eben du folgst wirklich deinem Plan, und sammelst die Daten erst, und ganz am Schluss ins Gui damit.
Weil derzeit siehts so aus, als ob jedes DatenItem sofort geadded wird, und das mag natürlich zu früh sein.

Testweise kannste auch ein Thread.Sleep einbauen, um diese Verfrühung mal vorläufig auszuschliessen.

Weil ich vermute, da werden noch weitere, andere Fehler folgen.

nun, du musst mein Snippet genau lesen: Form1.BeginINvoke ist nicht Me.BeginInvoke!

Form1.BeginINvoke kann nur failen, weil Form1 ist ein Datentyp, ist aber kein Objekt - denk mal über den Unterschied nach.

---

pts schrieb:

Wenn alles schief geht, werde ich einfach in Thread 1 das Form und das Listview programmatisch erzeugen... dann hab ich sicher kein Problem mehr mit den Zugriffen.

Wirst dich wundern.
Aber v.a.: Fang nicht mit iwelchen krickel-krückel-Workarounds an, wo keiner mehr durchblickt, nur weil du den graden, logischen Weg noch nicht hinbekommst.
Bleib dran am Lernen, wies richtig geht, sonst lernst (und gewöhnst dir an) wie's falsch geht.

Ach - und beachte, dass dein neuer Fehler ein anderer ist als der Vorherige. Anfänger denken immer "Immer noch der Fehler", aber tatsächlich ists ein großer Fortschritt, wenn man den ersten Fehler überwunden hat, und nun auf den 2. stossen kann.

Jo, dassis jetzt der FolgeFehler, den ich bereits in post#8 vermutete: Du kannst in einem NebenThread auch kein ListViewItem erstellen.
Also auch das Erstellen von ListViewItem muss im MainThread erfolgen.

Das liegt doch bestimmt wieder an der komischen Auto-Instanzierung von VB.Net, die aus VB6-Relikten übrig blieb.

pts schrieb:

MainForm:
Form1.Show()

instanziert ein neues Objekt der Klasse Form1 und führt dort .Show aus.

pts schrieb:

In Thread1:
Form1.BeginInvoke(Sub() Form1.TestListView.Items.Add(tempLvItem))

instanziert ein neues Objekt von Form1 und versucht dort .BeginInvoke auszuführen.
Das ist aber eine andere Instanz als die in MainForm erzeugte.
Weil die noch nicht angezeigt wurde, gibt es kein Handle dafür.

Wenn der Thread in derselben Klasse wie Mainform codiert ist, müsste die besagte Adressierung mit Me funktionieren.
Wenn der Thread in einer anderen Klasse (oder Modul) codiert ist, funktioniert das Verfahren nicht mehr.
Ich habe das dann immer so gelöst, dass ich dem aufgerufenen Thread einen Pointer zum Aufrufer mitgegeben habe.

Heute geht das eleganter mit Async.

Edit: Ich sehe gerade, dass ihr in der Zwischenzeit einen Schritt weiter seid.

pts schrieb:

Ok Warum den das? Ist es nicht egal, wo ich eine Variable erzeuge?

Kurze Antwort: Nein.

Wahrscheinlich in dem anderen Formular, von dem Du glaubst, es sei Dein Hauptformular, es aber nicht ist, wie petaod schon schrieb. Schau mal hier vorbei.

in einem anderen ListView, auf einem anderen Form1, in einem anderen Thread.
Ich sagte ja: Form1 ist ein Datentyp, und kein Objekt.
Dummerweise generiert VB doch ein Objekt davon, sodass der Fehler nicht aufschlägt.
Noch dummererweise, wenn im NebenThread aufgerufen, generiert VB dort auch ein Form1-Objekt.
Dann hast du 2, komlette Objekte des Typs Form1: Das eine siehste auffm Bildschirm, das andere existiert nur im Nebenthread, unsichtbar, denn niemand hat seine .Show-Methode aufgerufen.

Aber guck auch VaporiZeds Link, da steht dasselbe etwas ausführlicher.

nein - alles gut. Bis auf dass du im NebenThread ListViewItems erstellst. Erstelle dort andere (Daten-)Objekte, um deine Daten aufzunehmen.
Und gib diese anderen Objekte zurück an den Mainthread, und erstell im Mainthread aus den Datenobjekten ListviewItem.

Möglicherweise musst du extra für deine Daten eine geeignete Daten-Klasse erschaffen.

Wie du siehst, bist du eiglich nahe dran, nur die "neben-frage" in post#16 hat dich vonne Linie abgebracht. Niemand hat gesagt, du müsstest auf irgendetwas warten (ausser eben, dass das Form schoma anzeigt, bevor .BeginInvoke aufgerufen werden kann - weil zuvor hats noch keine Handle).