J'écris une application WinForms qui a deux modes: console ou GUI. Trois projets au sein d'une même solution, un pour l'application console, un pour les formulaires d'interface utilisateur et le troisième pour conserver la logique selon laquelle les deux interfaces se connecteront également. L'application Console fonctionne parfaitement.Erreurs d'interface utilisateur d'inter-threads étranges
Un modèle qui contient les utilisateurs-sélections, il a une IList<T>
où T est un objet local, Step
, qui implémente INotifyPropertyChanged
, donc dans l'interface utilisateur est montée sur ce à un DataGridView. Tout va bien à l'exécution, l'état initial des objets est reflété sur l'écran.
Chacun des objets Step
est une tâche qui est effectuée à tour de rôle; certaines propriétés vont changer, reflétées dans IList et transmises à DataGridView.
Cette action dans les versions de l'interface utilisateur est effectuée en créant un BackgroundWorker relançant des événements dans l'interface utilisateur. Le Step
le fait et génère un objet StepResult
qui est un type énuméré indiquant un résultat (par exemple Running, NotRun, OK, NotOK, Caveat) et une chaîne pour indiquer un message (parce que l'étape a couru mais pas tout à fait comme prévu, c.-à-d. une mise en garde). Normalement, les actions impliquent une interaction avec la base de données, mais en mode débogage, je génère aléatoirement un résultat.
Si le message est nul, il n'y a jamais un problème, mais si je produis une réponse comme ceci:
StepResult returnvalue = new StepResult(stat, "completed with caveat")
je reçois une erreur disant que le DataGridView était accessible à partir d'un fil autre que le fil il a été créé le. (Je passe ceci à travers un handler personnalisé qui devrait gérer l'invocation si nécessaire - peut-être pas?)
Ensuite, si je génère une réponse unique, par ex. en utilisant un nombre aléatoire r
:
StepResult returnvalue = new StepResult(stat, r.ToString());
les actions réussissent sans problème, les chiffres sont écrits proprement le DataGridView.
Je suis déconcerté. Je suppose que c'est en quelque sorte un problème littéral de chaîne, mais quelqu'un peut-il venir avec une explication plus claire?
Pas exactement la réponse - mais dans le bon sens! – Unsliced
Perfick! Exactement ce dont j'avais besoin pour lier des collections dans une DLL à partir de clients Winforms et WPF, merci. – Wonko
Cela fonctionne uniquement si BindingList a été créé dans le thread d'interface utilisateur, non? Mais existe-t-il une solution, si BindingList <> est créé en dehors du thread de l'interface utilisateur? Et non, nous ne pouvons pas passer ISynchronizeInvoke correspondant ou SynchronizationContext à BindingList :( –