Discussion :

[zax-tfh]

Bonjour à tous,

Je fais face à un ptit soucis qui je pense a été traité déjà auparavant mais je ne trouve pas mon bonheur sur le web

J'utilise un backgroundworker pour charger une liste d'images que je colle ensuite dans des controles picturebox (pour l'exemple, car en fait je travaille en wpf, mais le probleme n'est pas situé à ce niveau).

Donc voici grosso modo le principe :

- j'ai 1 Sub qui charge tous les noms de fichiers images dans un arraylist puis appelle le dowork du backgroundworker en lui envoyant la liste en parametre.

- Dans le dowork, j'ai une boucle qui, pour chaque element de mon arraylist créé un objet (c'est une classe a moi, mais bon, en gros c'est une classe qui a une property pour le chemin de l'image et une autre property qui est l'objet bitmap lui meme).
A la fin de ma boucle, je me retrouve avec un objet de type List(Of MaClasseImage) que j'envoie dans le e.result

- Dans le workcompleted, je recupere la liste d'images via le e.result que je caste bien entendu en type List(Of MaClasseImage). avec ce resultat, j'envoie tout ca dans l'interface mais là ca crashe car il me dit qu'il ne peut acceder à un objet créé dans un autre thread.

Message d'erreur complet : Le thread appelant ne peut pas accéder à cet objet parce qu’un autre thread en est propriétaire.

Ma question est la suivante : comment faire pour transmettre l'objet d'un thread à un autre ?

Edit : petite précision : je me situe dans une classe donc je n'ai pas acces au dispatcher de la fenetre comment faire autrement ?

Merci d'avance
@ bientot

[Pol63]

les objets héritant de la classe control doivent etre instancié sur le thread principal, tout le reste peut à priori être fait sur l'autre thread

un objet de type bitmap, il doit donc pouvoir etre créé sur ton thread

l'évènement workcompleted est biein relégué dans le thread principal pourtant ...


instancies tu des controles ?


une feinte pour aller dans le thread principal depuis une classe de faire application.openforms(0).invoke()

[zax-tfh]

En fait j'ai l'impression qu'il y a un schmilblik dans ma classe... Mais plus précisement, dans le fonctionnement global. Voici le principe schématisé (ca va pas etre evident a faire :

Mon appli avec mes controles -> possede une instance de ma classe projet -> ma classe projet chargeant les images via un backgroundworker -> au retour du backgroundworker, je sette ma property Monprojet.images avec le resultat de mon bgworker -> le binding est censé se mettre à jour sur l'interface via le changement de propriété (car ma classe projet implemente InotifyPropertyChanged).

Donc je me demande si c'est pas le binding qui vient mettre le souc... (mais là j'ai l'impression que ca touche trop à WPF, donc il faudrait que je fasse déplacer le sujet dans la section adequate ...

[Pol63]

le mot dispatcher m'avait mis la puce à l'oreille, et tu aurais en effet du préciser que tu étais sur WPF

en wpf je ne vois pas de backgroundworker, j'en déduis donc que tu as utilisé celui de windows forms

et entre windows forms et wpf, la notion de thread principal diffère légèrement à priori

donc ca se trouve l'évènement du backgroundworker n'arrive pas à se remettre sur le thread principal, donc essaye de le faire toi meme

et en wpf le dispatcher du thread principal est trouvable depuis une classe

essaye avec un code du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
 
Private Delegate Sub DelegateSubA
 
Public Sub A
    If Windows.Threading.Dispatcher.CurrentDispatcher IsNot Application.Current.Dispatcher Then
      Dim d As New DelegateSubA(AddressOf A)
      Application.Current.Dispatcher.Invoke(d)
      Exit Sub
    End If
 
    ' traitement
End Sub

[zax-tfh]

En fait, par rapport aux essais que j'ai déjà faits, le backgroundworker fonctionne très bien avec wpf.
Néanmoins, de par la strucure globale de ma classe, je me pose des questions.
En fait il y a une chose que je ne comprend pas avec le backgroundworker :

Dans la methode DoWork d'un backgroundworker, si on créé un objet, et qu'on le passe dans le result, au moment ou on le recupere dans le RunWorkerCompleted via le e.result, à qui appartient-il ? le thread du backgroundworker ou le thread principal ?
Comment faire pour etre sur de le balancer sur le thread principal ? avec le dispatcher ? (si oui, j'ai déjà essayé... et ca plante toujours. Malheureusement, je ne peux débugger le truc car a priori c'est dans la partie Framework (et je suis quasi sur que cela vient du refresh du binding objet car tout se deroule bien en pas à pas et c'est seulement quand je quitte la derniere instruction qui doit etre executée que ca me lance une exception du type j'utilise un objet créé dans un autre thread que celui qui doit l'utiliser)

Je sens que je vais galerer pour trouver !

[Pol63]

essaye sans backgroundworker à tout hasard, via un thread


dim th as new system.threading.Thread(adressOf departSub)
th.Start


dans tous les cas plutot que de passer un paramètre au démarrage, essaye d'utiliser une variable de classe accessible depuis tous les threads


ca vient surement du binding, mais ca devrait marcher quand meme
en instanciant ta variable avant d'appeler le traitement asynchrone, l'instance appartient au thread principal