IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Windows Presentation Foundation Discussion :

DependencyProperty et multithreading ?


Sujet :

Windows Presentation Foundation

  1. #1
    Expert éminent sénior Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    Avril 2007
    Messages
    14 150
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 150
    Points : 25 066
    Points
    25 066
    Par défaut DependencyProperty et multithreading ?
    bonjour

    une dependencyproperty ne peut pas etre assignée par un autre thread

    j'ai une dependencyproperty qui est un observable collection d'un classe héritant de dependencyobject

    sur un autre thread je créé un autre observablecollection que je set sur ma dependencyproperty via un dispatcher.invoke dans le but de pouvoir au moins gérer mes données sur un autre thread
    déjà ca plante (il me dit que le observable collection of maclasse n'est pas une valeur pour un observable collection of maclasee (aller comprendre ce que ca veut dire ...))

    mais apparement les objets créé sur l'autre thread ne peuvent alors plus utilisés par le thread principal

    en bref, les dependencyproperty c'est bien gentil, mais le multithreading est essentiel de nos jours, les 2 sont ils absolument incompatibles ??
    microsoft ferait des modifs dans tous les sens sans pouvoir toutes les utiliser en meme temps (les parrallel.foreach arrivant sur le framework 4 en plus ...) ??
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  2. #2
    Membre expérimenté
    Profil pro
    Inscrit en
    Juillet 2008
    Messages
    1 562
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2008
    Messages : 1 562
    Points : 1 313
    Points
    1 313
    Par défaut
    j'avais donne un link sur un sujet analogue
    creer des uielement dans un trhead pour les passer au thread principal
    tu devrais le regarder
    IKEAS : Finalement je crois que c'est dans ses faiblesses que l'on y trouve a la fois de la force et a la fois de la richesse...
    ----------------------------------------------------
    Si vous avez du taf en wpf & design d'application sympa, contactez moi !!!!
    http://ultimatecorp.eu/wpf/

  3. #3
    Expert éminent sénior Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    Avril 2007
    Messages
    14 150
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 150
    Points : 25 066
    Points
    25 066
    Par défaut
    je pense avoir retrouvé ton lien

    la solution serait de transformer les uielement en xaml puis de les recréer sur le thread principal à partir du xaml
    faudrait voir ce que ca donne niveau perf ...


    mais est-ce que tout peut se transformer en xaml ? un dependencyobject aussi ??
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  4. #4
    Expert éminent sénior Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    Avril 2007
    Messages
    14 150
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 150
    Points : 25 066
    Points
    25 066
    Par défaut
    c'est bien ce que je pensais, on ne peut pas tranformer n'importe quoi en xaml

    mais question reste donc ...
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  5. #5
    Rédacteur
    Avatar de Thomas Lebrun
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    9 161
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 9 161
    Points : 19 434
    Points
    19 434
    Par défaut
    Citation Envoyé par sperot51 Voir le message
    mais apparement les objets créé sur l'autre thread ne peuvent alors plus utilisés par le thread principal
    Seules les classes statiques et les objets qui sont dans un état gelé (Frozen) peuvent être échangés entre les threads.

    Sinon, je ne comprend pas ta question/ton pb...

  6. #6
    Expert éminent sénior Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    Avril 2007
    Messages
    14 150
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 150
    Points : 25 066
    Points
    25 066
    Par défaut
    pour résumer, je rempli un observablecollection avec une classe héritant de dependencyobject

    la collection est remplie et les objets instanciés sur un thread séparé

    j'ai un binding sur une propriété de ma window

    je veux placer la nouvelle collection dans cette propriété

    et là ca plante
    aux vues des différents messages d'erreurs, un dependencyobject ne peux pas passer d'un thread à l'autre, et un observablecollection non plus


    et frozen n'existe que pour les classes graphiques ...
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  7. #7
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    Février 2004
    Messages
    19 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2004
    Messages : 19 875
    Points : 39 749
    Points
    39 749
    Par défaut
    Je me permets de dévier un peu de la question de départ...
    Quelle est le rôle de ta classe qui hérite de DependencyObject ? (métier/UI/autre ?) Est-ce qu'elle ne pourrait pas plutôt implémenter INotifyPropertyChanged ?

    Si c'est pour un ViewModel (pattern MVVM), il est généralement admis qu'il vaut mieux implémenter INotifyPropertyChanged qu'hériter de DependencyObject (à ce sujet, voir cet excellent article, et cette discussion sur StackOverflow). Personnellement je préfère de loin l'approche POCO (INotifyPropertyChanged), parce qu'elle est beaucoup moins contraignante et donc beaucoup plus flexible (même si elle demande parfois d'écrire un peu plus de code).

  8. #8
    Expert éminent sénior Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    Avril 2007
    Messages
    14 150
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 150
    Points : 25 066
    Points
    25 066
    Par défaut
    je tente avec inotifypropertychanged pour voir ce que ca donne
    mon bouquin préconisait les DP plutot que les propertychanged ...
    et les DP ont l'air mieux niveau perf si j'ai bien lu



    sinon je pourrais aussi dériver ma question de départ, wpf permet une parfaite synchronisation de l'interfaces avec des collections de données, avec très peu de code
    mais comment faire pour synchroniser une base de données avec des collections ?

    je suis parti sur un thread genre timer qui toutes les x secondes va lire dans la base pour faire que la collection reflète les éventuelles modifications qu'il y a eut (par un autre user par exemple)

    qu'est-ce qui est le mieux niveau performance et volume de code ?
    pour l'instant je recréé une collection à chaque tour, je compare cette collection avec la collection utilisée comme viewmodel et je fais les eventuelles modifs, ajout, suppression, ou modification d'une propriété, les clés ne changeant pas
    pour l'instant je teste sur une classe avec deux propriétés donc ca se passe bien, mais y a t il une méthode plus adaptée à des grandes classes et des grands volumes de données ?
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  9. #9
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    Février 2004
    Messages
    19 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2004
    Messages : 19 875
    Points : 39 749
    Points
    39 749
    Par défaut
    Citation Envoyé par sperot51 Voir le message
    je tente avec inotifypropertychanged pour voir ce que ca donne
    mon bouquin préconisait les DP plutot que les propertychanged ...
    et les DP ont l'air mieux niveau perf si j'ai bien lu
    Les DP sont parfaites pour certains usages, par exemple pour les propriétés de contrôles personnalisés, et d'une manière générale pour ce qui touche à l'interface graphique. Mais pour le reste... tu viens de voir par toi-même un des inconvénients majeurs
    Pour ce qui est des perfs, l'auteur dit que les DP sont théoriquement plus performantes, mais que la différence est probablement négligeable. D'ailleurs ce serait intéressant de faire des tests là-dessus...

    Citation Envoyé par sperot51 Voir le message
    sinon je pourrais aussi dériver ma question de départ, wpf permet une parfaite synchronisation de l'interfaces avec des collections de données, avec très peu de code
    mais comment faire pour synchroniser une base de données avec des collections ?

    je suis parti sur un thread genre timer qui toutes les x secondes va lire dans la base pour faire que la collection reflète les éventuelles modifications qu'il y a eut (par un autre user par exemple)

    qu'est-ce qui est le mieux niveau performance et volume de code ?
    pour l'instant je recréé une collection à chaque tour, je compare cette collection avec la collection utilisée comme viewmodel et je fais les eventuelles modifs, ajout, suppression, ou modification d'une propriété, les clés ne changeant pas
    pour l'instant je teste sur une classe avec deux propriétés donc ca se passe bien, mais y a t il une méthode plus adaptée à des grandes classes et des grands volumes de données ?
    là j'avoue que je sais pas trop... j'ai pas encore été confronté à cette problématique

  10. #10
    Membre habitué Avatar de Thrud
    Profil pro
    Développeur .NET
    Inscrit en
    Avril 2008
    Messages
    170
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Avril 2008
    Messages : 170
    Points : 183
    Points
    183
    Par défaut
    mais comment faire pour synchroniser une base de données avec des collections ?
    ça dépend pas mal de la base avec laquelle tu travailles et du niveau d'abstraction que tu veux.
    La plupart des bases de données aujourd'hui sont capables d'envoyer des notifications quand il y a des modifications sur les données d'une table ("Continuous Query Notification" pour oracle par exemple, et peut-être "Notification Services" pour SQL server). Je ne connais pas les mécanismes offerts par d'autres SGBD, mais ça doit se faire aussi.

    Sinon, en passant par des triggers sur update/insert, tu peux aussi mettre en place un mécanisme similaire.

    Si plusieurs utilisateurs peuvent faire des modifs sur les données, la solution par timer qui va vérifier tous les x secondes me semble un peu hasardeuse, suivant le nombre d'utilsateurs, tu risques de tenter assez souvent de mettre à jour des données pas à jour.

  11. #11
    Expert éminent sénior Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    Avril 2007
    Messages
    14 150
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 150
    Points : 25 066
    Points
    25 066
    Par défaut
    oui y a les notifications de requete sur sql server (que j'utilise)
    j'ai aussi pensé à un mécanisme pour connaitre les maj

    je sais pas encore vers quoi je vais m'orienter les 2 n'étant ayant des inconvénients ...
    m'enfin vérifier tous les tant de temps c'est pas mieux en effet ! ^^
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [Kylix] Multithreads la galère
    Par Oyoboy dans le forum EDI
    Réponses: 16
    Dernier message: 16/07/2004, 12h03
  2. [WinAPI C++] MultiThreading et PostMessage
    Par Gruik dans le forum Windows
    Réponses: 7
    Dernier message: 29/03/2004, 16h58
  3. [WinAPI C++] MultiThreading?
    Par Gruik dans le forum Windows
    Réponses: 2
    Dernier message: 25/03/2004, 01h08
  4. [Win32]App multithread
    Par billyboy dans le forum Windows
    Réponses: 5
    Dernier message: 25/09/2003, 10h57
  5. Multithreading sous HP Ux 11
    Par pykoon dans le forum Autres éditeurs
    Réponses: 1
    Dernier message: 19/10/2002, 00h36

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo