kann CheckForIllegalCrossThreadCalls Probleme verursachen?

  • VB.NET
  • .NET (FX) 4.0

Es gibt 22 Antworten in diesem Thema. Der letzte Beitrag () ist von Mono.

    kann CheckForIllegalCrossThreadCalls Probleme verursachen?

    Hi, ich wollte mal wissen ob die funktion Control.CheckForIllegalCrossThreadCalls = False bei Threads die z.b. auf Labels oder TextBoxen probleme bereiten kann? Denn eigentlich arbeitet man ja bei Threadübergreinde sachen immer mit Invoke, aber diese Methode wäre ja wesentlich einfacher, nur frage ich mich halt ob das auch nachteile mit sich zieht?

    Natürlich. Du deadlockst Deine Anwendung damit ganz einfach und unterdrückst entsprechende Fehler einfach.

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    Auf keinen Fall..

    Nutze die Invoke-Methode (System.Windows.Forms).

    C#-Quellcode

    1. new Thread(new ThreadStart(() =>
    2. {
    3. Invoke(
    4. new MethodInvoker(delegate
    5. {
    6. bttn.Text = "HELLO FROM OTHER THREAD";
    7. }));
    8. })).Start();


    Grüße.

    EDIT: Sorry. Hab nicht zu Ende gelesen.
    Du nutzt schon Invoke, ups.

    2010
    Und Gott alleine weiß alles am allerbesten und besser.

    Dieser Beitrag wurde bereits 7 mal editiert, zuletzt von „φConst“ ()

    im Thread kanste auch einfach so mit ner mehrzeiligen Methode Invoken. Oder einfach eine Sub callen via Invoke.

    VB.NET-Quellcode

    1. Sub ThreadFunction()
    2. Me.BeginInvoke(Sub()
    3. Me.Text = ""
    4. Me.Heiligenschein = Sun.Shines.BrightOnMe
    5. End Sub)
    6. End Sub


    Ohne gross Ahnung davon zu haben, hat mich das Illegal im Namen schon gestoert.
    And i think to myself... what a wonderfuL World!

    Danke erstmal für die schnellen Antworten.
    Klar sollte man Fehlermeldungen Behandeln, aber ich frage mich ob dies wirklich als Fehlermeldung gewertet werden kann, denn immerhin Funktioniert es und die Anwendung arbeitet korrekt. Und wozu hat Microsoft denn CheckForIllegalCrossThreadCalls mit in die Framework eingebaut, oder dient das nur zu Testzwecken seiner Anwendung?

    @Mr. Johny wobei die Verswendung von anonymen Methoden auch nicht das Allheilmittel ist (Snippets von @φConst und @Eddy ).
    Wenn da mehr zu tun ist, empfehle ich, eine separate Methode zu erstellen. Die ist einfacher zu erweitern und sie kann debuggt werden. Das ist für mich entscheidend.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    nafets schrieb:

    ...wenn du aus mehreren Threads gleichzeitig auf das selbe Control zugreifst, stürzt die Anwendung uU einfach ab.
    Das tückische daran ist, dass sie nicht immer abstürzt, sondern nur bei sog. "race-conditions", wenn die Threads zufällig mal ganz besonders blöd an iwelchen internen Daten herummachen.
    Also eine ungesicherte Anwendung kann alle Tests bestehen, und erst beim Kunden zeigt sie sich dann als instabil (die Crashs passieren unvohersehbar gelegentlich).
    Da muss man dann erst drauf kommen, dasses an einem inkompetent umgesetzten MultiThreading liegt.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Soweit ich weiß funktioniert CheckForIllegalCrossThreadCalls sowieso nur beim Debuggen. In einer Releaseversion hat das keine Bedeutung und die Fehler werden geworfen.

    LG
    Das ist meine Signatur und sie wird wunderbar sein!

    Mono schrieb:

    beim Debuggen
    Jou, das ist so: MSDN.
    Das wäre dann allerdings noch ein Grund mehr, das abzuschaffen. :/
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    @TE: Wenn du schon dieses CheckForIllegalCrossThreadCalls verwenden musst bzw dir Sorgen machst, dass das evtl ned funzt, solltest du dir eher mal überlegen, ob dein Design vielleicht nicht falsch ist.

    Ich hab selber z.B ein Projekt, bei dem ich in meiner naivität und meiner damaligen unwissenheit das aktualisieren der Daten im UI in einen Task ausgelagert und greife da auch auf das UI per Form.Invoke zu. Wenn ich dazu komme, werd ich mir mal das Projekt vornehmen und das ganze umbauen (warscheinlich Observer Pattern). Dann brauch ich auch nicht mehr quer über die Threads greifen. Da aktualisiere ich einfach die Werte in einer Datennspeicherklasse und lasse dann die Datenspeicherklasse das UI benachrichtigen, dass sich die Werte geändert haben. Das UI wiederum holt sich dann die Werte selbstständig ab.

    Könntest du in dei nem Projekt auch mal versuchen.

    Lg Radinator
    In general (across programming languages), a pointer is a number that represents a physical location in memory. A nullpointer is (almost always) one that points to 0, and is widely recognized as "not pointing to anything". Since systems have different amounts of supported memory, it doesn't always take the same number of bytes to hold that number, so we call a "native size integer" one that can hold a pointer on any particular system. - Sam Harwell

    Also dann war es offenbar andersrum. Das CheckForIllegalCrossThreadCalls = True funktioniert nur bei Debugger.IsAttached. Das heißt im Release wird die Anwendung nicht abstürzen, auch wenn CheckForIllegalCrossThreadCalls = True ist und eine Exception fliegen würde. (Es ist aber möglich diese mit Try abzufangen) Wenn ein Debugger attached ist, dann wird die Anwendung auch durch die Exception unterbrochen.
    Das ist meine Signatur und sie wird wunderbar sein!

    Mono schrieb:

    im Release wird die Anwendung nicht abstürzen, auch wenn CheckForIllegalCrossThreadCalls = True
    Nö.
    Release mit und ohne Debugger:
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Mono schrieb:

    gar nichts
    Mathematische Logik: Ein Gegenbeispiel genügt.
    In jedem Falle blöd.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

Facebook
Telefonspende