Hallo zusammen,

ich habe eine verzwickte Situation: Ich habe in meinem Projekt eine bisher funktionierende Client-"Server-App"-Verbindung über TCP/IP. Der Client fordert Daten an und sobald er sie vom Server erhält, wird ein Event nebenläufig gefeuert, welches die gelieferten Daten enthält. Soweit so langweilig und bisher auch gut laufend. Bei einem Testprojekt habe ich aber etwas entdeckt, bei dem ich nicht mehr durchblicke. Ich konnte nach langer Fehlersuche und Umbauten, die kaum noch was mit der Client-Server-Verbindung zu tun hat, es auf folgende, sonderbare Situation eindampfen:

• Ich lese im Event nur eine gültige XML-Datei ein und übergebe die Daten an ein tDS (typisiertes DataSet) per ReadXML.
  
• Sind es wenige Daten (< 7 Datensätze, je bestehend aus einer Int32-ID und einem String), geht es. Es bestehen keine Contraint-Probleme.
  
• Bei mehr Daten hängt sich die App auf - aber nur, sofern sie als eigenständige EXE gestartet wird! In Visual Studio 2017 CE gestartet läuft die App auch mit mehr Daten.
  
• Wird die Datei nicht im nebenläufigen Event geladen, läuft es auch bei vielen Daten in der eigenständigen EXE.
  

Ich interpretier das alles als Symptome. Aber die Ursache finde ich nicht. Was kann ich noch machen, um das eigentliche Problem zu identifizieren? Oder kann mir jemand sagen, was ich falsch mache?

##########

OK, ich konnte das Problem auf einen Punkt reduzieren - den ich aber immer noch nicht verstehe.
Die Daten landen in einem tDS. Ein DGV ist daran gekoppelt.

Jetzt kommt's:
Ist die DGV-SmartTag-Option »Hinzufügen« (Property AllowUserToAddRows) aktiviert, hängt sich die EXE beim Daten-Laden auf. Ist sie deaktiviert, läuft die App. WTF

---

Lösung in Post#9

@NoIde: explizit Threads: nein, Nebenläufigkeit mit Tasks bzw. Async/Await: ja. Denn?
@VB1963: Hab ich auch schon mal probiert, leider kein Erfolg: Vor Start der Event-auslösenden Funktion: BindingSource.SuspendBinding(); nach dem Laden, im Hauptthread: BindingSource.ResumeBinding()

##########

Es klappt zwar, dass ich zu Beginn oder im Designer AllowUserToAddRows auf False setze und nach Laden der Daten wieder auf True, aber das ist eher ein Umgehen eines noch nicht von mir erkannten Problems und hat was von "und immer schön dran denken" - was früher oder später dann doch untergeht.

Tja, was soll ich sagen: Anbei ein zusammengesetzter Screenshot. Links in VS ausgeführt, rechts als EXE. Rechts eben das klassische Formular-ist-nicht-mehr-ansprechbar-Verhalten.

Langsam schein ich aber dem Problem näher zu kommen. Im Zuge der Screenshoterstellung wollte ich natürlich das alles ein wenig schöner aussehen lassen. Da ist mir aufgefallen, dass nicht die Option AllowUserToAddRows das Problem ist, sondern die Tatsache, dass, wenn durch das Datenhinzufügen das Aussehen des DGVs geändert wird, nämlich das Hinzukommen von Scrollbars, sich die Exe aufhängt. Dass nebenläufige Aufgaben nicht die CEs des Main-Threads explizit ändern dürfen, ist mir klar. Aber hier wird das DGV-CE ja implizit durch den Datenimport verändert. Und dies scheint das Problem zu sein. Wenn das stimmt, na dann vielen Dank.

##########

Verflucht, das kann es aber auch nicht (nur) sein, da meine anderen Apps, die mit dem gleichen Aufbau versehen sind, problemlos auch als selbständige EXE laufen

##########

Anbei mal das ganze minimalistisch. Ist das DGV groß genug, läuft's. Ansonsten rebelliert (anscheinend nur) die EXE.

Wie Du dem Projektupload entnehmen kannst: ja.
Sonst würden sich zweifellos irgendwelche FileNotFound-, DllLinker- oder andere Exceptions zeigen.

##########

Es wird immer mysteriöser. Habe eine meiner »funktionierenden« Apps hergenommen und im Laufe der Fehlersuche ein Duplikat des dortigen DGVs erstellt. Danach hängt sich die EXE auf. Nehm ich das DGV-Duplikat raus, läuft es wieder. Habe die DGV-Daten in der Designer.VB verglichen. Alles Relevante gleich (außer Position und TabIndex). Habe auch eine der DGV-Spalten vom Original ins geleerte Duplikat verschoben, um auszuschließen, dass es an den Spalteneinstellungen liegt. Funktioniert auch nicht.
Und noch verrückter: Wenn ich CheckForIllegalCrossThreadCalls = False anfangs einschalte, funktioniert auch die App in VS nicht mehr. Umgekehrt hätte es für mich Sinn ergeben, also dass nun die EXE läuft. Aber dass sie mit diesem no-go-Befehl nicht mehr in VS läuft, überfordert mich.

Ok, ich hab zwar keine Ahnung, warum RaiseListChangedEvents mein Problem löst, aber es funktioniert.
Das Rätsel mit dem funktionierenden Erst-DGV ist zwar immer noch ungelöst, aber wurscht.
Bist Du auf die Lösung damals per Trial-and-Error drauf gekommen oder durch entsprechende Recherche?

Na ganz toll. Einmal, weil es durch die Prüfung flutscht und ein anderes mal, weil es sich erst zeigt, wenn die Scrollbars sichtbar werden.
Herzlichsten Dank, das Wochenende ist (für den Moment) gerettet.