Pourquoi l'exception d'opération de thread croisé n'est pas levée lors de l'exécution de exe dans bin \ Debug

Question

Je déboguais une application et quelque part dans le code, un thread essayait d'atteindre une listbox créée par un autre thread. Lors d'une tentative d'accès à la liste, l'application lance une opération inter-thread non valide: Control 'listbox' accédé à partir d'un thread autre que le thread sur lequel il a été créé "exception lors du débogage. Cependant, lorsque j'exécute la sortie de cette application dans le dossier bin \ Debug, je n'obtiens pas de dialogue d'exception et je vois que la liste est accessible depuis le thread non-propriétaire, ce qui me fait penser qu'il y a une différence de comportement , pas seulement une exception supprimée. Je peux aller au-delà de cette exception dans le débogage avec la ligne suivante dans l'événement Form_Load

Control.CheckForIllegalCrossThreadCalls = false; 

Mais quelle est la raison derrière ce comportement différent?

Answer 1

Oui, ceci n'est vérifié que lorsqu'un débogueur est connecté. Cela était nécessaire car il y avait lots du code .NET 1.x qui violait cette règle. Ce n'est pas une évidence.

Le plus gros problème est qu'un tel code s'en est tiré avec. Soit par chance, ne pas trop penser aux problèmes de peinture occasionnels ou en pensant que l'abandon de l'application quand il est dans l'impasse et le redémarrage une fois par jour était acceptable. Parce que le programmeur n'avait aucun espoir réel de découvrir le problème sans diagnostic.

Microsoft se soucie beaucoup de compat backward, même si c'est compat buggé. Le correctif est excellent, même si c'est parfois faux (Show (propriétaire) est coché quand ce n'est pas le cas). Et oublie parfois de vérifier quand c'est du code dans le framework qui viole la règle. Ce qui se passe lorsque la dépendance du thread est indirecte. Les cas les plus fréquents sont la mise à jour de la source de données d'un contrôle lié aux données dans un thread de travail (unbind first!) Et l'utilisation d'un contrôle à l'écoute de l'événement SystemEvents.UserPreferenceChanged (ne créez pas d'interface utilisateur sur un second thread!)

---

Pour référence, le code correspondant est présent dans le constructeur statique de la classe de contrôle:

static Control() 
{ 
    //... 
    checkForIllegalCrossThreadCalls = Debugger.IsAttached; 
    //... 
}