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

VB.NET Discussion :

Méthode utilisées par 2 Threads [Débutant]


Sujet :

VB.NET

  1. #1
    Membre éclairé
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mars 2012
    Messages
    640
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Bâtiment

    Informations forums :
    Inscription : Mars 2012
    Messages : 640
    Par défaut Méthode utilisées par 2 Threads
    Bonsoir a tous,
    Je commence a peine a me lancer dans le multithread et je rencontre un problème d’accès a une méthode a partir de plusieurs Threads, je m'explique :
    Actuellement j'utilise une méthode pour Désactiver des événements le temps de faire de gros traitements sur des DataTable, puis pour réactiver ces événements dés que les traitements sont terminés. cette méthode est appelée ponctuellement a divers endroit de mon code mais toujours depuis le Thread principale (Thread A) ce qui ne pose aucun problème.

    Aujourd'hui j'ai besoin de faire la même action mais depuis un Thread secondaire (Thread B) seulement les Threads risquent de se faire concurrences aux niveaux des Activation/Désactivation. Il faudrait que si Thread A désactive les Events, alors Thread B n'a pas le droit les réactiver tant que Thread A n'a pas terminé et réactivé ces Events, (il doit attendre sont tour). Idem depuis Thread B. (Le fonctionnement normal de l'application veux que ces événements soit toujours activés en temps normal). Je ne sais pas du tout comment faire cela.

    Cela donne un truc du style :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    ActiveControlesHandler(False)
    ' ici on lance des opérations sur un DataTable
    ActiveControlesHandler(True)
    Le code pour Désactiver/Activer les évenements :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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
    Dim ControleHanddlerIsActive As Boolean
    Public Sub ActiveControlesHandler(ByVal State As Boolean)
     
            If State = True And ControleHanddlerIsActive = False Then
                AddHandler DataGridView1.CurrentCellDirtyStateChanged, AddressOf EventCurrentCellDirtyChanged
                AddHandler MainBindingSourcePaths.CurrentItemChanged, AddressOf EventbsCurrentItemChanged
                AddHandler MainBindingSourcePaths.CurrentChanged, AddressOf EventbsCurrentChanged
                AddHandler MainBindingSourcePaths.PositionChanged, AddressOf EventbsPositionChanged
                AddHandler dtTablePaths.ColumnChanging, AddressOf EventTableColumnChanging
                AddHandler dtTablePaths.ColumnChanged, AddressOf EventTableColumnChanged
                AddHandler dtTablePaths.TableNewRow, AddressOf EventTableNewRow
     
                ControleHanddlerIsActive = True
            ElseIf State = False And ControleHanddlerIsActive = True Then
                RemoveHandler DataGridView1.CurrentCellDirtyStateChanged, AddressOf EventCurrentCellDirtyChanged
                RemoveHandler MainBindingSourcePaths.CurrentItemChanged, AddressOf EventbsCurrentItemChanged
                RemoveHandler MainBindingSourcePaths.CurrentChanged, AddressOf EventbsCurrentChanged
                RemoveHandler MainBindingSourcePaths.PositionChanged, AddressOf EventbsPositionChanged
                RemoveHandler dtTablePaths.ColumnChanging, AddressOf EventTableColumnChanging
                RemoveHandler dtTablePaths.ColumnChanged, AddressOf EventTableColumnChanged
                RemoveHandler dtTablePaths.TableNewRow, AddressOf EventTableNewRow
     
                 ControleHanddlerIsActive = False
            End If
        End Sub
    Je vous remercie beaucoup pour votre aide.

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

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 202
    Par défaut
    à côté de la méthode ActiveControlesHandler tu met une variable privée as integer

    quand tu rentres dans la méthode avec false tu fais +1 dessus, si l'int = 1 tu désactive
    quand tu rentres avec true, tu fais -1, si l'int = 0 tu actives
    ainsi lors du 2ème appel avec false l'int vaudra 2 et exit sub car ne vaut pas 1 (et ca aura été désactivé à 1)
    lors du 1er true tu passes de 2 à 1 et exit sub car pas 0
    lors du 2eme true tu passes à 0 et ca réactive

    par contre il faut un synclock, ou alors l'incrémentation atomique mais je ne sais plus où elle est car en multithreading si 2 threads passent en même temps sur la ligne varint += 1 il se peut qu'en partant de 1 on arrive à 2 au lieu de 3
    chaque thread va lire la valeur (1) puis faire +1 (2) puis ranger dans la variable
    il faut donc interdire à 2 threads de faire ca en même temps
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  3. #3
    Membre éclairé
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mars 2012
    Messages
    640
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Bâtiment

    Informations forums :
    Inscription : Mars 2012
    Messages : 640
    Par défaut
    Bonsoir et merci de m'avoir répondu.
    J'ai dus relire plusieurs fois car au début j'ai cru que cela ne réglait le problème qu'a moitié, en effet avec cette technique on ne mets pas en attente le Thread B si le Thread A a débuter une opération. En y réfléchissant bien c'est vraiment très astucieux car en effet il est inutile de vouloir rentrer dans la procédure (et mettre un Thread en attente) afin de la désactiver si celle-ci l'a déjà été par un autre Thread. Et la réactivation ne s'effectue que si il n'y a plus aucun Thread qui nécessite une désactivation.

    Franchement vous êtes quelqu'un sur le site a données des réponses pertinentes a chaque fois, ça me laisse admiratif.
    Je ne marque pas résolue tout de suite car je dois procéder a des essais, je le ferais plus tard. Et encore merci

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

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 202
    Par défaut
    je veux bien croire qu'il faille relire plusieurs fois, c'est juste prémaché, il faut modéliser le tout pour comprendre le fonctionnement

    sinon il faut bien cerner la problématique, si le but est de laisser en attente un thread il y a synclock qui permet de faire ca, ou éventuellement le readerwriterlockslim qui permet de gérer des cas de manière plus optimisé que synclock

    si votre thread répond à une demande de chargement et que votre 2ème thread doit remplacer le traitement du 1er il y a mieux que de verrouiller l'accès, il faut annuler le 1er avec là aussi plusieurs méthodes

    la technique que je vous ai donné c'est pour permettre de suspendre quelque chose dans le cas de x entrées de la méthode jusqu'à la xième sortie en gros
    si vos 2 threads ont réellement besoin de faire le travail en même temps ca devrait convenir
    on trouve ce genre de comportement dans le framework, comme dans la méthode suspendlayout/resumelayout, on peut appeler suspend plusieurs fois, et il faut appeler resume autant de fois pour réactiver le calcul du layout
    décompiler le framework quand on veut comprendre comment marche l'outil qu'on utilise est une des méthodes qui permet d'apprendre plein de techniques
    poser des questions pertinentes ici a l'air d'en être une autre ^^
    il y a aussi des tutos sur les design pattern les plus courants, qui sont des méthodes connues qui répondent à des problématiques, de conception ou de performance (singleton, factory, lazy initialization etc...)


    pour l'incrément atomique c'est interlocked.increment/decrement(variable)
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  5. #5
    Membre éclairé
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mars 2012
    Messages
    640
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Bâtiment

    Informations forums :
    Inscription : Mars 2012
    Messages : 640
    Par défaut
    Merci beaucoup pour l'explication.
    En fait je ne sais pas très bien ce qu'il faut verrouiller, c'est là tout le problème. La seule chose dont je suis sûre c'est que je dois désactiver ces événements lors de certaines opérations et je ne maîtrise pas vraiment le moment quand ces opérations se produisent et donc il y a une probabilité pour que les Threads travaillent en même temps.
    Voilà ou j'en suis pour l'instant :

    J'ai ajouté une région critique afin de garantir la réactivation des événements en cas d’interruption du Thread.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    Thread.BeginCriticalRegion()
    ActiveControlesHandler(False)
    ' ici on lance des opérations sur un DataTable
    ActiveControlesHandler(True)
    Thread.EndCriticalRegion()
    A la place de 0 et 1, je fait un test avec -1 et 0, cela m’évite d'initialiser la variable lors de la première activation.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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
    Dim ControleHanddlerIsActive As Boolean
    Dim ControleHandlerCounterOfDésactive As Integer
    Public Sub ActiveControlesHandler(ByVal State As Boolean)
     
            If State = False Then
                Interlocked.Increment(ControleHandlerCounterOfDésactive)
            Else
                Interlocked.Decrement(ControleHandlerCounterOfDésactive)
            End If
     
            If State = True And ControleHanddlerIsActive = False And ControleHandlerCounterOfDésactive = -1 Then
                AddHandler DataGridView1.CurrentCellDirtyStateChanged, AddressOf EventCurrentCellDirtyChanged
                AddHandler MainBindingSourcePaths.CurrentItemChanged, AddressOf EventbsCurrentItemChanged
                AddHandler MainBindingSourcePaths.CurrentChanged, AddressOf EventbsCurrentChanged
                AddHandler MainBindingSourcePaths.PositionChanged, AddressOf EventbsPositionChanged
                AddHandler dtTablePaths.ColumnChanging, AddressOf EventTableColumnChanging
                AddHandler dtTablePaths.ColumnChanged, AddressOf EventTableColumnChanged
                AddHandler dtTablePaths.TableNewRow, AddressOf EventTableNewRow
                Debug.Print(String.Format("Les évenements ont été activés par le tread [{0}] <{1}>", Thread.CurrentThread.ManagedThreadId, Thread.CurrentThread.Name))
     
                ControleHanddlerIsActive = True
            ElseIf State = False And ControleHanddlerIsActive = True And ControleHandlerCounterOfDésactive = 0 Then
                RemoveHandler DataGridView1.CurrentCellDirtyStateChanged, AddressOf EventCurrentCellDirtyChanged
                RemoveHandler MainBindingSourcePaths.CurrentItemChanged, AddressOf EventbsCurrentItemChanged
                RemoveHandler MainBindingSourcePaths.CurrentChanged, AddressOf EventbsCurrentChanged
                RemoveHandler MainBindingSourcePaths.PositionChanged, AddressOf EventbsPositionChanged
                RemoveHandler dtTablePaths.ColumnChanging, AddressOf EventTableColumnChanging
                RemoveHandler dtTablePaths.ColumnChanged, AddressOf EventTableColumnChanged
                RemoveHandler dtTablePaths.TableNewRow, AddressOf EventTableNewRow
                 Debug.Print(String.Format("Les évenements ont été désactivés par le tread [{0}] <{1}>", Thread.CurrentThread.ManagedThreadId, Thread.CurrentThread.Name))
     
                 ControleHanddlerIsActive = False
            End If
        End Sub
    Pour l'instant je pense que l'on est sur la bonne voie mais quelque chose me dit que je devrais peut être rajouter un Synclock/End SyncLock et je ne sais pas comment exactement ni si cela est vraiment nécessaire. En effet je n'ai pas nécessairement besoin de mettre un Thread en attente a condition que ma procédure soit suffisamment vérouillées (c'est ma crainte), c'est a dire que dans le cas ou 2 threads rentre en même temps dans la procédure il ne faudrait pas que l'un active pendant que l'autre désactive ou encore que cela entraîne une erreur dans le décompte de la variable integer car ensuite je ne pourrais plus réactiver. Je ne sais pas trop répondre a cette question.
    Bien sûr dans mon programme pour chaque désactivation correspond une réactivation, les appels sont équilibrés.

    Merci beaucoup si vous pouvez m'aider.

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

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 202
    Par défaut
    je ne connaissais pas Thread.BeginCriticalRegion, je vais regarder ce que ca donne
    mais si j'ai bien compris ca sert à arrêter l'appli suite à un abort, et je ne suis pas sur que vous ayez compris la même chose ...
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  7. #7
    Membre éclairé
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mars 2012
    Messages
    640
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Bâtiment

    Informations forums :
    Inscription : Mars 2012
    Messages : 640
    Par défaut
    Merci Pol63,
    En effet j'ai un gros doute, j'ai peut-être mal compris. Il me semblait que le Thread devait attendre d'être sortie d'une région critique avant de pouvoir effectivement s'interrompre en particulier dans le cas d'un Abort. En tout cas si une telle fonction existe je pense que c'est ce qu'il faudrait faire dans mon cas. L'ideal serait que cela fonctionne aussi dans le cas d'une levé d'exception dans le Thread mais peut-être que j'en demande beaucoup

  8. #8
    Membre Expert Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Par défaut
    Bonjour.

    Il me semble que le problème est mal abordé et à mon avis désactiver ces événements pour un traitement de fond n'est pas souhaitable.

    Premier problème : quel est le scénario exact ? Mon petit doigt me dit que ces événements sont normalement utilisés pour répondre à des actions de l'utilisateur mais qu'ils répondent également à des actions automatisées, ce qui n'est pas désirable. D'où le désabonnement avant ces actions automatisées. Juste ? Si oui il faut se rappeler que des actions de l'utilisateur peuvent survenir durant les actions automatisées effectuées en arrière-plan, donc se désabonner avant une action en arrière-plan ne serait pas la bonne solution.

    Second problème : les contrôles UI ne peuvent être manipulés que depuis le thread sur lequel ils ont été créés (il y a une "affinité avec un thread" / "thread affinity"). Et par extension les tables liées à l'UI ne doivent être manipulées que depuis le thread UI. Un thread d'arrière-plan doit donc séparer les calculs purs qu'il réalise lui-même, des opérations de mise à jour de l'UI qui devront être envoyées vers le thread UI via Control.Invoke/BeginInvoke.

    Partant de là deux scénarios possibles :
    * Faire les calculs en arrière-plan et mettre à jour le datatable sur le thread UI. Valable uniquement si les calculs sont majoritaires.
    * Créer un nouveau datatable en arrière-plan, puis l'attacher à l'UI.

    Dans les deux cas la MAJ de la vue sera faîte uniquement sur le thread UI, donc se désabonner avant et se réabonner après ne posera pas de problème.



    Régions critiques
    Une "région critique" n'a d'effet que lorsque la CLR est hébergée par un processus natif (SQL Server, IIS, mode debug de VS, etc). Si une exception asynchrone (StackOverflow, OutOfMemory et ThreadAbort) survient dans une région critique, alors l'hôte considérera le domaine d'application comme corrompu et le déchargera.

    Le raisonnement est simple : ces exceptions sont difficilement gérables car elles peuvent survenir n'importe quand ! Par exemple dans "maVariable = AllocUnamnagedMemory()" une exception peut survenir après l'allocation mais avant l'assignation, rendant le nettoyage impossible. De même une exception peut survenir après l'acquisition d'un verrou mais avant l'entrée dans un bloc "try". Et ainsi de suite. Il est parfois impossible (littéralement) d'écrire un code managé résilient.

    Ainsi, quand SQL Server héberge le CLR, il gère plusieurs domaines d'applications piochant tour à tour des procédures managées en attente d'exécution. Si une exception asynchrone survient dans un de ces domaines, SQL Server laisse les choses suivre leur cours (l'exception peut être interrompue et gérée par le code, ou bien elle peut continuer à remonter, en vidant la pile d'appels). Mais si cette exception est survenue dans une région critique, alors SQL Server détruira purement et simplement le domaine d'application avant d'en recréer un.

    Une région critique indique donc que si une des trois exceptions asynchrones survient, alors le domaine d'application doit être considéré par l'hôte comme corrompu et détruit. Et s'il n'y a pas d'hôte ça n'a aucun effet. A ne pas confondre avec une "section critique", terme de Win32 qui désigne un bout de code protégé par un verrou.

  9. #9
    Membre éclairé
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mars 2012
    Messages
    640
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Bâtiment

    Informations forums :
    Inscription : Mars 2012
    Messages : 640
    Par défaut
    Bonsoir DonQuiche, merci pour ton intervention.
    Mon petit doigt me dit que ces événements sont normalement utilisés pour répondre à des actions de l'utilisateur mais qu'ils répondent également à des actions automatisées, ce qui n'est pas désirable. D'où le désabonnement avant ces actions automatisées. Juste ?
    C'est exactement ça. Au départ j'ai utilisé ces événements pour répondre aux actions utilisateurs (Principalement pour valider des données dans ColumnChanging ou faire apparaître un formulaire de saisie dans TableNewRow). Puis j'ai eu besoin d'actualiser des données au moment du chargement, je me suis rapidement rendu compte que je n'avais pas besoin de validation des données durant cette tache, d'ou les désabonnements. (a ce moment là l'interface utilisateur n'est pas accessible donc ça ne présente aucun risque). J’aurais pu le faire différemment je suis tout a fait d'accord que c'est une faiblesse de mon application mais je m'en rend compte que maintenant. En même temps je ne suis qu'un amateur, je fait des erreurs et j'apprends.

    les contrôles UI ne peuvent être manipulés que depuis le thread sur lequel ils ont été créés (il y a une "affinité avec un thread" / "thread affinity"). Et par extension les tables liées à l'UI ne doivent être manipulées que depuis le thread UI
    Pour les contrôles, c'est clair ça lève de suite une exception Cross-Threads mais pour les tables je ne savais pas. En réalité les interventions utilisateurs sur la table en question se limite a supprimer des enregistrements pendant que le traitement automatique en ajoute ou modifie des existants, cela expliquent peut-être pourquoi je n'ai jamais rencontré de problèmes ?!

    puis l'attacher à l'UI
    En quoi consiste l'opération attacher exactement ?

    Merci pour l'information sur les régions critiques.

    @Pol63, j'ai décider de ne pas utiliser Abort pour arrêter le thread car je ne maîtrise pas le moment précis de son interruption. Je préfère tester une variable boolean "StopRequest" dans une boucle pour pouvoir sortir de la boucle et quitter le Thread au moment que j'ai choisis. Ensuite je fait un Join.
    Concernant les exceptions j'ai ajouté un bloc Try comme ceci pour limiter les risques :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    ActiveControlesHandler(False)
    Try
     ' ici on lance des opérations sur un DataTable
    Catch ex As Exception
     
    End Try
    ActiveControlesHandler(True)
    J'ai implémenté tous ça sur mon application réel, ça ne semble pas poser de problèmes mais je ne suis pas contre d'autres éventuels conseils ou réponses a ce qui a été dit plus haut.

  10. #10
    Membre Expert Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Par défaut
    Citation Envoyé par BasicZX81 Voir le message
    je suis tout a fait d'accord que c'est une faiblesse de mon application mais je m'en rend compte que maintenant.
    En soi ce n'est nullement une faiblesse, on voit ça tout le temps. Là où ça coince c'est quand tu peux avoir des opérations manuelles de l'utilisateur durant les traitements automatisés : dans ce cas tu es obligé de garder tes événements pour les traitements utilisateur et ton approche ne convient plus (il suffit de faire une édition durant le traitement de fond pour voir le bogue : pas de validation).

    Si c'est bien ce que tu avais compris et que tu voulais dire que tu peux te permettre ce bogue, ok. Mais sinon il y a une solution : utiliser les mécanismes standard de validation puisque c'est ce que tu veux faire. A savoir utiliser les événements CellValidating, RowValidating et Validating de DataGridView. Ceux-ci ne seront déclenchés que suite à des actions manuelles de l'utilisateur et avant la mise à jour de la DataTable liée.


    Pour les contrôles, c'est clair ça lève de suite une exception Cross-Threads mais pour les tables je ne savais pas.
    A vrai dire j'ai un doute. Il se peut que le DataGridView vérifie le thread courant lors de la levée de DataTable.TableNewRow afin de réaliser la mise à jour sur le thread UI si besoin est. Donc peut-être pas de problème.


    En réalité les interventions utilisateurs sur la table en question se limite a supprimer des enregistrements pendant que le traitement automatique en ajoute ou modifie des existants, cela expliquent peut-être pourquoi je n'ai jamais rencontré de problèmes ?!
    Autre problème : deux threads réalisent donc simultanément des opérations d'écriture sur cette même datatable ? Si oui tu risques une corruption des données puisque DataTable n'est pas thread-safe dans ce genre de scénario. La solution est de modifier cette table depuis le thread UI exclusivement si tu veux conserver le data binding.


    En quoi consiste l'opération attacher exactement ?
    Un mauvais choix de mot. "Assigner" aurait été plus judicieux, pour l'assignation de la nouvelle DataTable à la DataGridView.

  11. #11
    Membre éclairé
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mars 2012
    Messages
    640
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Bâtiment

    Informations forums :
    Inscription : Mars 2012
    Messages : 640
    Par défaut
    Si c'est bien ce que tu avais compris et que tu voulais dire que tu peux te permettre ce bogue, ok.
    C'est pas vraiment ce que j'aurais voulu au départ mais je suis conscient du problème. Pour l'instant ça ne me gène pas plus que ça mais a terme j’essaierais de trouver une meilleure solution, c'est juste que ça remets en cause toute l'architecture de mon programme et je ne suis pas prêt a le faire .
    Pour la petite histoire, je m'était posé la question concernant la meilleure façon de traiter les actions utilisateurs sachant que je voulais produire un code (de calculs/validations) facilement transposable pour d'autres tables et indépendant des contrôles (ce que j'ai réussi a faire). Pour cela j'ai utilisé a fond (ou presque) le databinding et l'endroit qui m'ai apparu comme le plus évident pour traiter les actions utilisateurs est l’événement ColumnChanging puisque ici converge absolument toutes les modifications et on a aussi la possibilité d'annuler les saisies non valide. Aprés je ne dit pas que l'on ne peux pas faire la même chose au niveau des contrôles. D'ailleurs c'est une question que je me pose depuis longtemps, a quelle endroit ou a quelle moment il vaux mieux faire les validations ? au niveau Datatable ou au niveau des contrôles ? J'ai un élément de réponse avec le problème des traitements automatique mais cela m'interresse vraiment beaucoup de savoir qu'elle est la pratique utilisé couramment dans le monde pro.

    A vrai dire j'ai un doute. Il se peut que le DataGridView vérifie le thread courant lors de la levée de DataTable.TableNewRow afin de réaliser la mise à jour sur le thread UI si besoin est. Donc peut-être pas de problème.
    Ça me mets le doute aussi mais j'ai tendance a dire que ça fonctionne puisque c'est une réalité dans mon programme, on voit bien des lignes apparaître toutes seules sur le DatagridView et cela depuis un thread secondaire sans utiliser d'Invoke/BeginInvoke.

    Autre problème : deux threads réalisent donc simultanément des opérations d'écriture sur cette même datatable ?
    Ben oui je crois c'est la simultanéité que je ne peux pas prouver mais effectivement je crois avoir rencontrer un petit soucis une fois. (une ligne que j'ai modifié a la main et qui n'a pas été trouvé par le traitement automatique (ou un truc dans le genre). Il faudra que je vérifie cela aussi.

    La solution est de modifier cette table depuis le thread UI exclusivement.
    Avec un Invoke donc si j'ai bien tout compris.

    Je songe a passer la discussion en résolue mais j'aimerais bien avoir votre avis sur la validation.

  12. #12
    Membre Expert Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Par défaut
    Concernant la validation la pratique courante est de la traiter via les événements "Validating" dédiés côté UI. Après tout ça a été conçu pour ça. Et de nos jours tous les contrôles/frameworks UI offrent des mécaniques standard de validation.

    La seule justification pour mettre en oeuvre une mécanique personnalisée c'est lorsqu'on n'est pas satisfait par la mécanique standard en termes d'expérience utilisateur. Par exemple si on souhaite valider à chaque frappe de l'utilisateur plutôt que lors de la perte du focus.

    Enfin, oui, il faut passer par Invoke. Tant pour la lecture de la table que pour sa modification.

  13. #13
    Membre éclairé
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mars 2012
    Messages
    640
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Bâtiment

    Informations forums :
    Inscription : Mars 2012
    Messages : 640
    Par défaut
    Merci pour ces renseignements DonQuiche. C'est toujours trés interressant d'avoir le point de vue des vrais developpeurs. Ca me servira pour mon expérience personnelle et peut-être pour améliorer mon programme.
    Je passe ne résolue.

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

Discussions similaires

  1. Changer la méthode exécuter par un thread
    Par sfaxien dans le forum C#
    Réponses: 3
    Dernier message: 17/12/2009, 16h17
  2. Méthode de redirection utilisée par Twitter et Facebook
    Par fixbraun dans le forum Débuter
    Réponses: 3
    Dernier message: 16/06/2009, 19h11
  3. Exécution d'une méthode par un thread
    Par melleb dans le forum C#
    Réponses: 1
    Dernier message: 18/09/2008, 11h21
  4. Réponses: 2
    Dernier message: 04/09/2007, 22h26
  5. utilisation par un fils d'une méthode qu'il surcharge ...
    Par money mark dans le forum Langage
    Réponses: 4
    Dernier message: 20/02/2006, 20h03

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