Discussion :

[boubounne]

bonjours a tous, je developpe actuellement une application en c#, et j'aurais besoin d'aide sur les openfiledialog. Voici la declaration que j'ai recupéré de la faq :

Code :

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

1
2
3
 
OpenFileDialog op = new OpenFileDialog();
op.show()

je l'ai un peu simplifier pour ne faire que l'affichage...
Le probleme est qu'il me dit a chaque fois que le STAtread n'est pas bon, et a vrai dire,j'ai rien compris a ca... je comprend que en groq c'est pour lancer un nouveau processus, qui va prendre la main par rapport au processus principal de l'application, mais je n'arrive pas a le placer dans mon code, si quelqu'un peu me donner un coup de main..

[ced600]

Peux tu montrer plus de code, parce que je pense que tu as trop simplifié là

[Gulix]

Est-ce que ta fonction Main possède bien l'attribut [STAThread] ?? (comme lorsque tu crées un projet WinForms)

[tomlev]

Je ne sais pas si ça a un rapport avec ton problème, mais en général on fait plutôt :

Code :

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

1
2
3
OpenFileDialog op = new OpenFileDialog();
op.ShowDialog()

[SirJulio]

Salut,

si le debugger "t'insulte" à propos d'un probleme d'appartment, c'est soit :

-que tu as oublié de marquer ton point d'entrée avec l'attribut [STAThread] (essentiel pour une appli winforms)

-que tu tentes d'ouvrir ton openfiledialog depuis un thread du pool (si tu as fait un ThreadPoo.QueueUserWork, un BeginInvoke sur un delegué ou autres choses appellant sur les threads du pool).

Bref, quand tu utilises Winforms, dans l'ideal, il ne faudrait jamais avoir un Thread en MTA (tous les threads managés sont par defaut en MTA, ceux nouvellement créé et ceux du pool), puisque si tu touches le Clipboard, un dialog ou autres, tu te retrouves avec une exception.

Bon courage.

[boubounne]

merci de vos reponses, je vois qu'il faut un thread MTA en effet. le probleme est que je ne sais pas comment faire. J'ai regardé les tuto mais rien ne marche.
Au passage, je ne veut pas faire mon thread dans le main, mais sur l'evenement click sur le bouton parcourir (comme un vrai windosien....)
j'ai essayé de faire [THREAD], puis mon code, mais la il rale encore (gentil c# gentil....)
De plus je ne trouve aucun tuto ou ils utilisent cet ?%##*!! de thread.. si quelqu'un peu m'eguiller un peu svp...

[TrEiZe85]

Il faut faire réference à l'assembly

Code :

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

using System.Theading;

Ensuite quelle erreur te met le compilateur ?????

[SirJulio]

Salut,

avis purement personnel et sans doute biaisé, mais ouvrir un OpenFileDialog sur un thread separé, je ne vois pas vraiment l'utilité (c'est une fenetre modale, donc derriere le parent, n'est pas sensé bosser). Enfin bon, voila le callback du bouton pour lancer le thread :

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
            this.button1.Click += delegate
            {
                Thread t = new Thread(
                    delegate()
                    {
                        OpenFileDialog opfd = new OpenFileDialog();
                        if (opfd.ShowDialog() == DialogResult.OK)
                        {
                            lock (sync)
                            {
                                this.filename = opfd.FileName;
                            }
                        }
 
                    });
                t.SetApartmentState(ApartmentState.STA);
                t.Start();
            };

Nota sync est un static object de l'appellant pour synchroniser l'accès à une variable string de l'appellant aussi.

[tomlev]

lol, SirJulio, décidemment tu aimes bien les delegate anonymes... tu devais être malheureux avant l'arrivée du FX 2.0

Sinon, moi aussi ça me semble bizarre de lancer le dialogue dans un thread séparé... je ne vois pas bien l'utilité d'un point de vue fonctionnel. Enfin, je ne connais pas les besoins de l'appli en question, donc peut-être qu'en fait ça se justifie...

[SirJulio]

lol, SirJulio, décidemment tu aimes bien les delegate anonymes... tu devais être malheureux avant l'arrivée du FX 2.0

Sinon, moi aussi ça me semble bizarre de lancer le dialogue dans un thread séparé... je ne vois pas bien l'utilité d'un point de vue fonctionnel. Enfin, je ne connais pas les besoins de l'appli en question, donc peut-être qu'en fait ça se justifie...

Les methodes anonymes, c'est le bien ! Dans "le feu de l'action", c'est la feature ultime pour les predicate, les comparer, et toutes ses fonctions de 2 lignes 1/2. Par contre, souvent je pleure à la relecture ou quand je passes mon appli sur Reflector. =D

[ced600]

Perso je n'accroche pas sur les méthodes anonymes. Dans mes conceptions je n'arrive jamais à un moment où j'en ai l'utilité, tout est toujours bien rangé dans une méthode d'un objet.
Par exemple pour faire une thread qui surveille un processus et dit toutes les secondes ok ou ko, je n'utiliserais pas de méthode anonyme, mes je créerais un objet et la ou les méthodes associées. Je trouve cela plus propre.

[tomlev]

Les methodes anonymes, c'est le bien ! Dans "le feu de l'action", c'est la feature ultime pour les predicate, les comparer, et toutes ses fonctions de 2 lignes 1/2.

+1 ! C'est tellement plus simple d'avoir à créer une méthode que tu sais même pas comment appeler tellement elle est insignifiante... Il y a un truc presque équivalent en Java, les classes anonymes, mais c'est beaucoup plus lourd comme syntaxe que les méthodes anonymes.

[ced600]

C'est pas jolie tout ça et en plus c'est la preuve que l'on a pas passé assez de temps sur la conception. Donc si l'on en arrive à vouloir faire une méthode anonyme pour éviter de faire une objet et une méthode c'est qu'il y a peut être un oublie dans la conception.
Je ne connais pas de design pattern qui recommande l'utilisation de structure ressemblant à des classes ou méthodes anonymes.

Je pense que : Informaticien != Codeur fou.

[tomlev]

les design patterns sont très bien pour orienter la conception, mais tu n'es pas obliger des les appliquer exactement, et ça ne t'interdit pas d'utiliser les spécificités de chaque langage si elles te simplifient la vie... si MS s'est donné la peine d'ajouter ça dans C#, c'est que ce n'était peut-être pas si aberrant...

[SirJulio]

les design patterns sont très bien pour orienter la conception, mais tu n'es pas obliger des les appliquer exactement, et ça ne t'interdit pas d'utiliser les spécificités de chaque langage si elles te simplifient la vie... si MS s'est donné la peine d'ajouter ça dans C#, c'est que ce n'était peut-être pas si aberrant...

Clairement, puis les patterns ne sont pas assez explicites (et ne sont pas fait) pour te dire si il faut matcher des resultats, comme ceci :

Code :

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

1
2
3
4
5
            List<UneClass> result = liste.FindAll(
                delegate(UneClass user)
                {
                    return (user.Id == 6);
                });

ou comme cela

Code :

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

1
2
3
4
5
6
7
8
       List<UneClass> result = liste.FindAll(new Predicate<UneClass>(PredicateUser));
 
[....]
 
        static bool PredicateUser(UneClass user)
        {
            return user.Id ==6;
        }

Ce mecanisme reste un mecanisme intrinseque à C#, apres à toi de les integrer ou non dans ta conception.

Comme je disais aussi, l'abus de methodes anonymes, ca rend tres vite un code fouillis (surtout que tu peux les chainer ! comme ci dessus), et ca peut entrainer des comportements inattendus (les accès multithreads à des variables capturées par la methode anonyme) si tu ne prends pas certaines dispositions. Mais apres ce sont plus des considerations de lisibilité que de conception. Personellement je prefere eviter d'alourdir mes classes avec des foncteurs (par exemple) d'1 ligne, je prefere l'implementer à l'endroit ou je m'en sers (souvent une seule fois), c'est beaucoup plus clair (AMHA bien sur).

Bref question de point de vue et d'habitude, mais c'est quand meme, une bon outil. Puis à ma decharge, je dirais que le potentiel "bordelifere" des methodes anonymes est sans commune mesure avec celui des types anonymes de C# 3.0. =p

[ced600]

Ouais, en fait je me disais qu'avant de discuter de ce qui est mieux, faudrait déjà savoir si c'est la même chose au niveau de l'IL. Je crois me souvenir qu'un de mes profs me disais que les méthodes anonymes etait traduite en une methode d'une classe en IL.
Si c'est le cas, le choix entre l'un et l'autre ne dépend que de la lisibilité que l'on veut donner au code.
Mais personnellement, je ne me suis jamais retrouver dans un cas où il etait mieux de remplacer une méthode d'une classe que j'ai crée par une méthode anonyme. D'où le fait que je mettais en doute une bonne conception.

[boubounne]

Je vois que mon poste vous lance dans une polemique interessante (si j'y comprennait quelque chose..),et j'en suis flatté , mais egalement desole de devoir stopper cette discussion aussi brutalement...

J'ai actuellement 2 appli en c#, une pour des tests de code(un vrai foutoire...), et l'appli qui sera donnée au client...

Dans l'appli de test, l'openfiledialog ne pose pas de probleme... par contre dans l'autre il me sort une thread ecxeption.. pourtant dans aucune des deux je n'ai de thread, et je n'en souhaite pas..(du moin autant que possible).
Ce que je ne comprend pas c'est que les 2 codes sont identiques et simple :

Code :

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

1
2
3
 
OpenFileDialog op = new OpenFileDialiog();
op.ShowDialog();

Si quelqu'un a une explication qui tient la route, je l'en remercie, sinon je vais retourner voir mon gourou afin d'exorciser mon appli....

[ced600]

Moi je voulais voir tout ton code, je soupsonnais une modification involontaire du cod généré par windows.
Exemple : si tu as des appli console, au dessus du même tu as un truc du genre [STATHREAD]. Si par malheur tu l'as enlevé ou modifier, alors cela ne marche plus.

[boubounne]

En effet ca doit etre ca, je fais des tests et je vous redit au cas ou... Merci et bonne discution....

[SirJulio]

Salut,

@Boubounne :

je plussoie Ced, le plus probable est l'oubli de l'attribut qui va bien sur ton point d'entrée, si ce n'est pas ca, il faut chercher toutes invocations asynchrones que tu aurais pu lancer (principalement le BeginInvoke sur un delegate). De plus, j'ai relu le fil, et par rapport à ce que tu disais ici, sache qu'il n'y a pas de thread different dans une appli Winforms (sauf si tu en lances de ta propre intiative). Quand tu cliques sur un bouton (par exemple), le thread qui va executé le callback (la methode attaché au click) est le thread qui a lancé Application.Run(), et ce dernier doit (enfin il est recommandé qu'il soit) en STA (d'ou l'attribut [STAThreadAttribute] sur la Main d'un nouveau projet Winforms).

@Ced600 :

Pour l'ajout des methodes anonymes à C# 2.0, il n'y a eu aucune modification coté IL, c'est consommé par le compilateur, l'IL n'en voyant jamais la couleur. En fait, le compilateur quand il rencontre une methode anonyme, va soit créé un nouveau type nested (avec un nom à coucher-dehors) sealed et private (qui porte d'ailleurs l'attribut CompilerGenerated pour eviter des problemes si on utilise la reflexion), si la methode anonyme 'capture' des variables. Dans ce type il créé une methode qui represente notre fameuse methode anonyme (qui ne l'ai plus du coup). Soit si la methode anonyme n'a pas besoin de capturer de variables, il injectera simplement une nouvelle methode dans le type courant.

Premiere chose, il vient intuitivement que nouveau type implique nouvelle instanciation d'objet, et c'est ce qui se passe. Par exemple pour ce code :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
            List<string> liste = new List<string>();
            for (int i = 0; i < 100; i++)
            {
                liste.Add(string.Format("Test{0}", i));
            }
 
            int j = 5;
            liste.FindAll(
                delegate(string s)
                {
                    return s.Length == j;
                });

Le compilateur m'a créé un type <>c__DisplayClass1 avec une methode de signature bool <Main>b__0(string), qu'il instancie avant l'appel de la methode anonyme, et qu'il rattache à un nouveau delegué Predicate<string>.Si je n'avais pas capturé la variable j et que j'avais directement fait "return s.Length == 5;", j'aurai simplement eu la nouvelle methode <Main>b__0 sans nouveau type. Donc en bref, le compilateur fait notre boulot, en creant la nouvelle classe qui va bien (si besoin est) ou une nouvelle methode pour le délégué.

Le principal probleme qui font que les methodes anonymes peuvent etre lourdes ou sources de comportements bizarres, est quand l'environnement lexical change pendant l'execution de cette derniere (typiquement dans un contexte multithreadé), par exemple sans anonyme, on voit tout de suite ce qui se passe avec un code comme ca :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
            for (int i = 0; i < 10; i++)
            {
                ThreadPool.QueueUserWorkItem(new WaitCallback(StartThread), i);
            }
 
[...]
 
        static void StartThread(object state)
        {
            int i = (int)state;
            Thread.Sleep(500);
            Console.WriteLine(i);
 
        }

Ca va m'afficher de 0 à 9 avec 1/2 seconde de decalage. Maintenant la meme chose en utilisant les methodes anonymes (enfin pas exactement mais c'est pour l'exemple =p) :

Code :

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

1
2
3
4
5
6
7
8
9
            for (int i = 0; i < 10; i++)
            {
                ThreadPool.QueueUserWorkItem(
                    delegate
                    {
                        Thread.Sleep(500);
                        Console.WriteLine(i);
                    });
            }

Ici, je vais avoir 10 fois "10", car la variable n'est pas capturée au moment de la creation (ce qui laisse penser qu"il n'y a pas eu d'instanciation) mais au moment de son evaluation ("Et la c'est le drame ..."). Pour s'en convaincre, il suffit de regarder le code généré (pas en IL mais en C# option aucune optimisation sur reflector, ca reste proche de l'IL tout en etant "human-readable") :

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
    WaitCallback <>9__CachedAnonymousMethodDelegate1;
    <>c__DisplayClass2 <>8__locals3;
    bool CS$4$0000;
    <>9__CachedAnonymousMethodDelegate1 = null;
    <>8__locals3 = new <>c__DisplayClass2();
    <>8__locals3.i = 0;
    goto Label_003B;
Label_0012:
    if (<>9__CachedAnonymousMethodDelegate1 != null)
    {
        goto Label_0025;
    }
    <>9__CachedAnonymousMethodDelegate1 = new WaitCallback(<>8__locals3.<Main>b__0);
Label_0025:
    ThreadPool.QueueUserWorkItem(<>9__CachedAnonymousMethodDelegate1);
    <>8__locals3.i += 1;
Label_003B:
    if ((<>8__locals3.i < 10) != null)
    {
        goto Label_0012;
    }

On comprend bien qu'il y qu'une seule instanciation de la classe generée à la compilation, et qu'en fait dans la boucle, le program incremente la variable public (<>8_locals3.i += 1) et quand les threads sortent de leurs pauses, la boucle etant finie depuis longtemps ils ont tous la meme valeurs. On peut resoudre cela en reecrivant comme suit :

Code :

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

1
2
3
4
5
6
7
8
9
10
            for (int i = 0; i < 10; i++)
            {
                int captureMe = i;
                ThreadPool.QueueUserWorkItem(
                    delegate
                    {
                        Thread.Sleep(500);
                        Console.WriteLine(captureMe);
                    });
            }

ici, le compilateur va capturer la nouvelle variable et donc va créer autant d'instance du type generé qu'il y a de tour de boucle, et on aura bien l'affichage escompté ('0 ... 1 ... 2 ......... 9) car les differentes instances ne partagent plus la meme variables, mais ont chacune capturées leur propre variable. Pour infos, le code généré :

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
    int i;
    <>c__DisplayClass1 <>8__locals2;
    bool CS$4$0000;
    i = 0;
    goto Label_002A;
Label_0005:
    <>8__locals2 = new <>c__DisplayClass1();
    <>8__locals2.captureMe = i;
    ThreadPool.QueueUserWorkItem(new WaitCallback(<>8__locals2.<Main>b__0));
    i += 1;
Label_002A:
    if ((i < 10) != null)
    {
        goto Label_0005;
    }

En conclusion, en general, le compilateur sait faire les bonnes optimisations pour gerer les methodes anonymes sans lourder les perfs (pas de nouveau type quand c'est inutile, pas 36 instanciations quand une seule suffit), par contre le probleme vient quand ces methodes capturent des elements exterieurs et que ces derniers changent en chemin (d'ou le 'peut avoir des comportements inattendus'), où dans ce cas une methode concrete peut etre plus facile à gerer.