[.Net] Ungültiger threadübergreifender Vorgang - Visual Studio 2017

[skorpionx (Gast)]

Ich schreibe unter Visual Studio 2017 ein Programm für
Serielle Schnittstelle. Empfang funktioniert ohne Fehler
wenn ich Daten in einen lokalen String schreibe. Ich versuche
aber die Daten (für Visualisierung)  in textBox zu schreiben.
Aber das bringt den Fehler:
„Ungültiger threadübergreifender Vorgang“

[Rufus Τ. F. (rufus)]

Du schreibst nicht "unter Visual Studio 2017", sondern Du schreibst in 
einer .Net-Sprache.

Das ist für die Fehlersuche wichtig.

Du hast offensichtlich (mindestens) zwei Threads, und versuchst aus 
einem Thread auf ein Objekt zuzugreifen, das einem anderen Thread 
gehört.

Das ist nicht zulässig.

https://docs.microsoft.com/en-us/dotnet/framework/winforms/controls/how-to-make-thread-safe-calls-to-windows-forms-controls

[c-hater (Gast)]

skorpionx schrieb:

> Ich schreibe unter Visual Studio 2017 ein Programm für
> Serielle Schnittstelle. Empfang funktioniert ohne Fehler
> wenn ich Daten in einen lokalen String schreibe. Ich versuche
> aber die Daten (für Visualisierung)  in textBox zu schreiben.
> Aber das bringt den Fehler:
> „Ungültiger threadübergreifender Vorgang“

Die Ereignisse von SerialPort erfolgen nicht im Kontext des 
Haupt-Threads des Programmes, der für das GUI zuständig ist. Deswegen 
haben nahezu alle GUI-Komponenten eine eingebaute Warnung, denn das GUI 
ist nicht threadfest, es würde also unkontrollierbare Scheisse 
passieren, wenn es diese Warnung nicht gäbe.

Um zu erreichen, was du willst, mußt du (etwas vereinfacht) das Ereignis 
des fremden Threads in den Kontext deines GUI-Threads zwingen. Dafür 
bieten die allermeisten GUI-Komponenten (als Erben von Control) 
freundlicherweise die passenden Methoden an, nämlich:

InvokeRequired
Invoke
BeginInvoke

Wenn du nach diesen Methoden googelst, wirst du sicher den Code 
hunderter Anwendungsfälle finden.

Aber Vorsicht: Viele davon sind nicht ganz korrekt, was zu Problemen 
(besonders beim Start oder beim Beenden der Anwendung) führen kann. 
Schuld sind meiner Meinung nach daran aber nicht die Verfasser der 
entsprechenden Code-Stellen, sondern allein Microsoft. Das Problem ist 
nämlich, dass InvokeRequired NICHT tut, was man von einer Methode 
dieses Namens erwarten könnte. Die hätte eigentlich heissen müssen: 
InvokeRequiredAndPossible und müsste ein Ergebnis liefern, anhand dessen 
man zwischen den drei relevanten Situationen unterscheiden kann...

[Matthias S. (da_user)]

Such die Fehlermeldung mal bei mycsharp, da gibt's ein gutes Howto.

[Frank L. (Firma: Flk Consulting UG) (flk)]

Hallo,
wie schon oben beschrieben, musst Du das Ganze synchronisieren.

        private delegate void DoEnableGuiDelegate(bool enable);
        private void DoEnableGuiExcute(bool enable)
        {
            UpdateCommands();
        }

        private void DoEnableGui(bool enable)
        {
            if (InvokeRequired)
            {
                Invoke(new DoEnableGuiDelegate(DoEnableGuiExcute), enable);
                return;
            }
            DoEnableGui(enable);
        }

Ich löse das in der Regel so, DoEnableGui wird vom Event aufgerufen. 
Hier wird geprüft, ob ein InvokeRequired notwendig ist, wenn ja, wird 
der Delegate erzeugt und die Methode rekursiv aufgerufen.

Funktioniert sauber und zuverlässig.

Die Implementierung erfolgt in dem Form, in dem die Ausgabe bzw. wie bei 
mir die Buttons enabled oder disabled werden sollen.

Gruß
Frank

[skorpionx (Gast)]

Es funktioniert. Mein erster Kontakt mit delegate und Invoke …
Es war ziemlich mühsam. Das was man beim googeln finden muss
man gut „filtern“.Außerdem hilft so genannte „intuitive 
Programmierung“...

[c-hater (Gast)]

skorpionx schrieb:

> Es funktioniert. Mein erster Kontakt mit delegate und Invoke …

So what? Jeder fängt irgendwann mal an.

> Es war ziemlich mühsam.

So what? Jeder Anfang ist mühsam.

> Das was man beim googeln finden muss
> man gut „filtern“.

Natürlich. Das Problem ist nur: wenn man von einer Sache wirklich 
absolut keine Ahnung hat, kann man eben nicht wirklich einschätzen, was 
man besser filtern sollte...

> Außerdem hilft so genannte „intuitive
> Programmierung“...

Was genau meinst du damit? Ich neige bis zu einer Erklärung eher dazu, 
dass du nicht wirklich kapiert hat, was du tust, dass es aber irgendwann 
mehr oder weniger zufällig geklappt hat. Dann kann ich dir schon 
vorhersagen, dass die kleinste Änderung im Code dafür sorgen wird, dass 
wieder Scheisse passiert...