Binding & Threading

Version imprimable

Binding & Threading

Bonjour,

Mon problème est le suivant:

J'ai un processus long qui s'execute et j'aimerai, pendant le déroulement de ce processus, remonter des informations sur l'activité en cours.

j'ai donc Bindé une collection d'objet TaskItem à une ListBox. Une tache ( Action globale) contient une liste de sous-tâches (information sur ce qui est executé par le processus long).

Afin de laissé la Thread UI tranquille, mon processus long s'execute bien evidement sur une autre Thread. Du coup, lorsque je met à jour la collection de sous-taches, une exception est générée car la modification est faite par une autre thread.

Je sais que je dois utiliser un dispatcher, mais je ne sais pas comment l'exploiter au travers du binding, les exemples que j'ai trouvé mettant toujours en oeuvre des propriétés directe d'un control. (TextBox.text). :calim2:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
 
public class TaskItem : INotifyPropertyChanged 
{
        private String mActionTask;
        private SubTaskItems mSubItems = new SubTaskItems();
        private eTaskState mState = eTaskState.Unknown;
 
        public enum eTaskState
        {
            Unknown,
            Executing,
            Completeted,
            Failed
        }
 
        public eTaskState State
        {
            get { return mState; }
            set 
            { 
                mState = value;
                if (PropertyChanged != null)
                    PropertyChanged(this, new PropertyChangedEventArgs("State"));
            }
        }
 
        public TaskItem(String actionTask)
        {
            mActionTask = actionTask;
        }
 
        public void addSubTask(eVerboseLevel level, String msg)
        {
            SubTask.Add(new SubTaskItem(msg));
        }
 
        public String ActionTask
        {
            get { return mActionTask; }
        }
 
        public SubTaskItems SubTask
        {
            get { return mSubItems; }
        }
 
        public override string ToString()
        {
            return mActionTask;
        }
 
        #region INotifyPropertyChanged Members
 
        public event PropertyChangedEventHandler PropertyChanged;
 
        #endregion
    }

Ci-dessous, la reprsésentation de mes ListBoxItem.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
<DataTemplate x:Key="ActionTaskItem">
 
            <Grid >
                <Grid.RowDefinitions>
                    <RowDefinition />
                    <RowDefinition />
                </Grid.RowDefinitions>
                <Grid.ColumnDefinitions>
                    <ColumnDefinition />
                    <ColumnDefinition />
                </Grid.ColumnDefinitions>
 
                <Image Name="mCurrentStateImage" Source="{Binding State, Converter={StaticResource taskItemStateConverter} }" Margin="5"  Grid.Column="0" Grid.RowSpan="2"  Width="24" Height="24" Stretch="Uniform" VerticalAlignment="Top" />
                <TextBlock Text="{Binding ActionTask}" Margin="5" Grid.Row="0" Grid.Column="1" Style="{StaticResource ListBoxItemActionTitle}"/>
 
                <Expander Header="{Binding SubTask.LastSubTaskItem}" Style="{StaticResource ListBoxItemActionDetail}"  IsExpanded="false" Margin="25,0,5,0" Grid.Row="1" Grid.Column="1" >
                    <ListBox ItemsSource="{Binding SubTask}" Margin="25,0,25,0" Background="Transparent"/>
                </Expander>
            </Grid>
 
        </DataTemplate>

Merci de m'eclairer, :oops:
Cordialement,

Ahryman40k.

26/12/2010, 18h25
Invité

Je vois bien où se situe ton problème, pour pallier tu peux utiliser un BackgroundWorker au lieu de la classe Thread.
En utilisant un BackgroundWorker, tu pourras utiliser soit l'évènement RunWorkerCompleted ou ProgressChanged pour mettre à jour ta collection sans passer par un dispatcher.
26/12/2010, 19h57
tomlev

En fait, la mise à jour d'un binding à partir d'un autre thread est supportée pour les propriétés (INotifyPropertyChanged), mais pas pour les modifications de collections (INotifyCollectionChanged).

Il faut donc faire les ajouts à la collection sur le thread de l'UI, en utilisant Dispatcher.Invoke, ou alors, comme suggéré par h2s84, dans l'évènement ProgressChanged d'un BackgroundWorker (qui est déclenché sur le thread de l'UI)

Sinon, j'avais écrit un truc à ce sujet sur mon blog, et j'avais proposé comme solution une classe qui hérite de ObservableCollection<T> et déclenche l'évènement CollectionChanged sur le thread de l'UI. Comme ça tu as juste à remplacer ton ObservableCollection par cette classe, et le reste du code ne devrait pas changer
27/12/2010, 12h12
Ahryman40k

Citation:

Envoyé par h2s84

Je vois bien où se situe ton problème, pour pallier tu peux utiliser un BackgroundWorker au lieu de la classe Thread.
En utilisant un BackgroundWorker, tu pourras utiliser soit l'évènement RunWorkerCompleted ou ProgressChanged pour mettre à jour ta collection sans passer par un dispatcher.

En fait, j'utilise déjà un BackgroundWorker.
Attendre l'evenement RunWorkerCompleted ne m'avancerait pas plus car cela reviend à attendre la fin de la thread. L'idee du ProgressChanged n'est pas bête, je me demande juste comment je vais transmettre ce qu'il se passe ailleurs a cette méthode.
Je crois que c'est possible à travers son evenement ? => j'etudie la solution !! :ccool:
27/12/2010, 12h16
Ahryman40k

Citation:

Envoyé par tomlev

En fait, la mise à jour d'un binding à partir d'un autre thread est supportée pour les propriétés (INotifyPropertyChanged), mais pas pour les modifications de collections (INotifyCollectionChanged).
Il faut donc faire les ajouts à la collection sur le thread de l'UI, en utilisant Dispatcher.Invoke, ou alors, comme suggéré par h2s84, dans l'évènement ProgressChanged d'un BackgroundWorker (qui est déclenché sur le thread de l'UI)

Ca me parait effectivement le plus simple et le plus rapide !

Citation:

Envoyé par tomlev

Sinon, j'avais écrit un truc à ce sujet sur mon blog, et j'avais proposé comme solution une classe qui hérite de ObservableCollection<T> et déclenche l'évènement CollectionChanged sur le thread de l'UI. Comme ça tu as juste à remplacer ton ObservableCollection par cette classe, et le reste du code ne devrait pas changer

Je vais analyser également cette solution.
Je signale dès que mon problème est résolu.
Merci pour toute vos réponses :lol:
27/12/2010, 12h28
Ahryman40k

Citation:

Envoyé par tomlev

Sinon, j'avais écrit un truc à ce sujet sur mon blog, et j'avais proposé comme solution une classe qui hérite de ObservableCollection<T> et déclenche l'évènement CollectionChanged sur le thread de l'UI. Comme ça tu as juste à remplacer ton ObservableCollection par cette classe, et le reste du code ne devrait pas changer

J'ai une question a propos de ta classe AsyncObservableCollection, il est spécifié que la collection doit etre créé sur la Thread UI, que se passe t'il dans le cas contraire ? Peut-on detecté qu'on est sur une thread UI ?
27/12/2010, 12h40
Invité
Citation:

Envoyé par Ahryman40k

J'ai une question a propos de ta classe AsyncObservableCollection, il est spécifié que la collection doit etre créé sur la Thread UI, que se passe t'il dans le cas contraire ? Peut-on detecté qu'on est sur une thread UI ?

Bon, je vais répondre à la place de tomlev.:lol:

Je pense qu'il n'y a aucun interêt que la classe soit définie dans un autre thread différent du thread UI :
- d'une part parce que ta classe ne sera accessible que par là où elle est définie et du coup impossible au Thread UI d'y accéder.
- d'autre part, c'est une collection qui peut être modifiée par plusieurs Thread lancés par le Thread UI donc autant définir la collection dans ce dernier.

Citation:

Envoyé par Ahryman40k

L'idee du ProgressChanged n'est pas bête, je me demande juste comment je vais transmettre ce qu'il se passe ailleurs a cette méthode.
Je crois que c'est possible à travers son evenement ? => j'etudie la solution !! :ccool:

Il y a une surcharge de ReportProgress qui permet de transmettre un objet en plus du pourcentage. Tu peux ensuite le récupérer dans le handler de l'évènement avec e.UserState :
Code:

1 2 3 4 5 6 7 8 9 ... backgroundWorker1.ReportProgress(percentage, newSubTask); ... void backgroundWorker1_ProgressChanged(object sender, ProgressChangedEventArgs e) { SubTask newSubTask = (SubTask)e.UserState; collection.Add(newSubTasks); }
Citation:

Envoyé par Ahryman40k

J'ai une question a propos de ta classe AsyncObservableCollection, il est spécifié que la collection doit etre créé sur la Thread UI, que se passe t'il dans le cas contraire ? Peut-on detecté qu'on est sur une thread UI ?

Les évènements seront déclenchés sur le thread où la collection a été crée. Vu que tu veux les déclencher sur le thread de l'UI, la collection doit être créée sur ce thread... ensuite tu peux la manipuler depuis n'importe quel thread.

Pour détecter si tu es sur le thread de l'UI, tu peux faire ça :
Code:

1 2 3 4 if (Application.Current.Dispatcher.CheckAccess()) { ... }
Citation:

Envoyé par h2s84

d'une part parce que ta classe ne sera accessible que par là où elle est définie et du coup impossible au Thread UI d'y accéder.

Non, n'importe quel thread peut y accéder (ce n'est pas un DispatcherObject). C'est juste que les évènements ne seront pas déclenchés sur le thread de l'UI, et donc ça fera la même erreur

En fait, je n'ai pas vraiment avancé car la solution avancée par tomlev n'est pas envisageable. Mon modele objet est comme suis:
Code:

1 2 3 4 5 6 7 8 9 10 11 class SubTaskItem; class SubTaskItems : IObservableCollection<SubTaskItem>; class TaskItem { private SubTaskItems mSubItems = new SubTaskItems(); }; class TaskItems : IObservableCollection<TaskItem>;
Ci-dessous, le code de ma page.
j'ai retiré tout ce qui n'est pas nécéssaire à la comprehension du problème.
Code:

1 2 3 4 5 6 7 8 9 10 11 public partial class ImportationStep : Page { private TaskItems mItems = new TaskItems(); //----------------------------------------------------------------- public TaskItems Tasks { get { return mItems; } } //----------------------------------------------------------------- }
La propriété Tasks definie ci-dessus est bindé dans une Listbox de ma page, et pour chaque ListBoxItem je vais bindé la propriété SubTasks de mon objet TaskItem.

L'erreur n'est pas provoquée lorsque j'ajoute une tache, mais lorsque j'ajoute une sous-tache.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 <Page> <Page.Resources> <DataTemplate x:Key="ActionTaskItem"> <Grid > <Image Name="mCurrentStateImage" Source="{Binding State, Converter={StaticResource taskItemStateConverter} }" /> <TextBlock Text="{Binding ActionTask}" /> <Expander Header="{Binding SubTask.LastSubTaskItem}" > <ListBox ItemsSource="{Binding SubTasks}" /> </Expander> </Grid> </DataTemplate> </Page.Resources> <Grid > <ListBox Name="mImportActionList" ItemsSource="{ Binding ElementName=ImportationStepPage, Path=Tasks, UpdateSourceTrigger=PropertyChanged }" ItemTemplate="{StaticResource ActionTaskItem}" IsSynchronizedWithCurrentItem="True" > </ListBox> </Grid> </Page>
Je suis dans un wizard d'importation dans lequel j'ai choisi d'utiliser des pages.
Lorsque je navigue sur cette page, j'initialise un Timer qui va lancer une procedure d'importation.

Durant l'importation, je vais executer plusieurs objets en tache de fond qui vont executer une etape de cette procedure d'importation. Je souhaite afficher au fur et à mesure ces etapes ainsi que des informations complementaires sur ce quelles font (les fameuses sous taches).
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 private void TimerProc(object sender, EventArgs e) { mTimerProc.Stop(); TaskItem excelDataExtractionTask = new TaskItem("Excel data checking"); excelDataExtractionTask.State = TaskItem.eTaskState.Unknown; mItems.Add(excelDataExtractionTask); BackgroundWorker mWorker = new BackgroundWorker(); mWorker.DoWork += new DoWorkEventHandler(DoExcelCheckCmd); mWorker.RunWorkerCompleted += new RunWorkerCompletedEventHandler(DoExcelCheckCmdCompleted); excelDataExtractionTask.State = TaskItem.eTaskState.Executing; mWorker.RunWorkerAsync( new DoExcelCmdArg( excelDataExtractionTask ) ); } private void DoExcelCheckCmd(object sender, DoWorkEventArgs e) { const String xlFile = @"G:\RJA Sample.xlsx"; DoExcelCmdArg arg = e.Argument as DoExcelCmdArg; try { ExcelCheckCommand xlsCheckCmd = new ExcelCheckCommand(xlFile); xlsCheckCmd.Verbose += new VerboseHandler(arg.TaskItem.addSubTask); xlsCheckCmd.execute(mXlsControlFile); } catch (System.Exception ex) { arg.TaskItem.State = TaskItem.eTaskState.Failed; } }
Mon erreur de thread se produit lorsque j'effectue ce lien :

Citation:

xlsCheckCmd.Verbose += new VerboseHandler(arg.TaskItem.addSubTask);

effectivement l'ajout d'une sous-tache se fait hors d'une thread UI.

Le temps de rediger tout ca, et ma reflexion avance, je me rend compte qu'au lieu de rendre bavarde ma commande tel que je l'ai faite, je pourrait utiliser le ReportProgress pour aboutir au même resultat et faire l'ajout de la sous-tache au même moment ...

Pensez-vous que c'est convenable comme solution ?

Le temps de vos reponse, je vais m'atteler a ces modifications et tester mon idée ...

Merci pour vos pistes.

27/12/2010, 16h18
tomlev

J'ai pas compris en quoi ma solution n'est pas envisageable... mais bon, tu as sans doute des éléments que je n'ai pas.

Au fait, il n'y a pas d'interface IObservableCollection<T>, seulement une classe ObservableCollection<T>. Et au lieu d'hériter de ça, tu pourrais hériter de AsyncObservableCollection<T>... non ?
27/12/2010, 17h30
Ahryman40k

Citation:

Envoyé par tomlev

J'ai pas compris en quoi ma solution n'est pas envisageable... mais bon, tu as sans doute des éléments que je n'ai pas.

La collection SubTaskItems, créé par l'objet TaskItem ne peux pas (ou plutot ce n'est pas sa place ) être créé sur la Thread UI.

Citation:

Au fait, il n'y a pas d'interface IObservableCollection<T>, seulement une classe ObservableCollection<T>.

Oui c'est une erreur de recopie quand j'ai fait mon post ...

Citation:

Et au lieu d'hériter de ça, tu pourrais hériter de AsyncObservableCollection<T>... non ?

Parfaitement d'accord, mais la solution ne plait pas dans la mesure ou si j'ai un model objet complexe avec un enchevetrement de collections, c'est à l'utilisateur de construire chaque sous-collections et de l'affecter proprement dans la hierarchie des objets ... Soit à peu prêt 14 chance sur 9 pour que ca deconne au premier tour et dans les suivants :mouarf: