Version imprimable
Bonjour
Je voudrais savoir comment on fait pour lancer un Form qui, après avoir été visible trente secondes, change,...
J'avais bien mis un thread.Sleep() dans le constructeur, et après le this.Visible(), mais tout ce que ça fait c'est que je ne vois mon Form qu'après que mon thread ai repris la main.
Si quelqu'un pouvait me donner un tuyau, ce serait sympa :D
PS: surtout dites si je n'ai pas été assez clair,...
:salut:
Détails un peut plus car c'est pas trés clair est si possible copier le code en question
Salut,
en effet je n'ai pas tres bien compris ce que tu voulais faire, mais en attendant, pourquoi ne pas utiliser un timer avec un interval de 30 secs qui gererai l'operation (le changement de form, ou autre), au lieu de d'endormir le thread principal de la form (ce qui fait que ta form au pire ne s'affiche pas, au mieux s'affiche mais est gelée).
Bref laisse ton thread de form tranquille et créé un timer qui gerera ce que la form doit faire (en invoquant le thread principal si besoin est).
Bah, c'est vrai que je n'avais pas pensé à utilisé un timer, mais, de toute manière je ne comprends pas pourquoi je ne réussis pas à :
1) je lance ma form
2) Je passe la main à un autre thread qui "passe le temps"
3) je reprends ma form
Et ça je ne réussis pas, quelque soit la manière dont je m'y prends, mon form ne s'affiche qu'après le délai d'attente d'un thread, qui peut pourtant même provenir d'une autre classe !
Et là j'y comprends plus rien ! :?
Peux tu poster ton code ?
sa doit venir tu fais que c'ezt ta form principale est tu dois faire une erreur dans le code
Bha, ok, voilà mon code, en gros (je mets que ce qui me semble nécessaire, mais si quelqu'un veut le code entier, je peut toujours le zipper):
//ça c'est dans le fichier Program.cs
//Et ça c'est dans le fichier Form1.csCode:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
//Et voila le fichier Debut.cs ( fabriquer juste pour résoudre mon problème de thread,...)Code:
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
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
PS: j'ai coupé dans le code, pour le rendre plus lisible, mais le compilo le lit très bien, donc ça ne devrait pas être une erreur de ponctuation ou un truc de ce genre,...
Moi je dirais que la réponse est là :
Citation:
pourquoi ne pas utiliser un timer avec un interval de 30 secs qui gererai l'operation (le changement de form, ou autre), au lieu de d'endormir le thread principal de la form (ce qui fait que ta form au pire ne s'affiche pas, au mieux s'affiche mais est gelée).
Oui, je pense aussi, en fait je suis presque certain, que ça marcherait, mais j'aimerais comprendre pourquoi ce que j'ai fait ne marche pas,...:?
Bah en fait dans la citation c'est aussi écrit pourquoi cela ne marche pas.
En fait tout marche correctement.
Tu crées ta forme, très rapide moins d'une seconde. Puis tu gèles ton programme. Donc c'est possible que la fenêtre ne s'affiche pas.
En fait ma fenêtre s'affiche bien, mais pas les objets qu'il y a à l'intérieur,...
Mais, ce n'est pas mon programme en entier que je veut geler, c'est seulement un thread, le thread de la classe Début,...
Et, si j'ai bien compris au lieu de bloquer seulement ce thread, il me gèle tout le programme ?
Alors, si quelqu'un sait comment faire pour séparer ce thread du thread principale ce serait sympa de m'expliquer, parce_que je patauge complètement,...:cry::cry:
Merci en tous cas pour l'aide
Je réponds de mémoire et je n'y connais pas grand chose mais
Si tu veux geler le thread de l'objet Debut, il faut que tu instancie ton objet Debut dans un autre thread que celui du programme principal. Aprés, j'ai jamais fait du multi-thread mais google est ton ami :mrgreen:Code:
2
3
4
5
6
7
8
Enfin, la méthode du timer me semble bien plus simple.
Salut Hurin,
le probleme quand tu geles le thread d'une Form (ou d'un control plus generalement), c'est que ce thread ne peut plus redessiner, rafraichir etc ... le Control. De fait la form peut etre dessinée, mais dans tous les cas elle n'inspecte plus la pompe à message, et par extension ne gere plus les callbacks de paint, et autres.
Vu qu'ici ton programme n'a qu'un thread, si tu le geles, tu geles tout. Meme en creant une nouvelle form, c'est le meme thread qui s'occupera des deux (un thread pouvant gerer plusieurs form à la fois) , donc en bloquant l'affichage de la deuxieme form, tu bloques la premiere par la meme. Voila pourquoi, ton seul salut, est d'utiliser un Timer (de toutes facons les thread.Sleep(), c'est un poil bricolage à mon gout =p)
OK, je me rends, je vais utiliser le timer,...:cry:
Mais tout de même, est-ce-que quelqu'un pourrait me dire comment faire pour faire du multi-threading, en clair coment faire pour instancier ma Form1 dans un thread différent que celui de mon thread principal ?
(Même si j'utilise un timer, d'ailleurs si quelqu'un ayant du temps pouvait me dire comment faire pour le timer, ça m'arrangerait, mais je pourrais chercher sur le net,...)
Merci encore d'avoir répondu :D
En clair, ce n'est pas possible. Tous les objets qui héritent de Control ainsi que les Form, sont forcément gérés par le thread principal, celui dédié à l'affichage en gros.Citation:
Envoyé par Hurin
Si jamais tu crées un Form dans un autre thread et que tu cherches à l'afficher, tu auras des surprises, de mémoire. Par exemple, crée un projet avec 2 Form (Form1, celle de démarrage, et Form2), et sur Form1 tu places un bouton et tu lui colles une méthode sur le clic (button1_Click dans l'exemple) qui servira à ouvrir la Form2 dans un autre thread.
Dans Form1, ca ferait quelque chose de ce genre
et lorsque tu auras cliqué sur le bouton tu constateras le problème, en gros ca plante grave ^^Code:
2
3
4
5
6
7
8
9
Le timer semble la bonne solution dans ton cas :)
et bien entendu personne n'a remarqué la cause de son problème
[STAThread] ... et oui UN SEUL ET UNIQUE THREAD PRINCIPAL POUR TOUT !!!
et personne encore n'a pensé à suggérer une utilisation de [MTAThread] ... en plus il y a TOUJOURS un moyen... tout est question de méthode de développement, surtout avec les threads.
Si il lance un thread séparé, et fou la paix à son thread principal... il ne le FREEZE PAS, encore faut t'il lancer un thread secondaire...
Salut,
à partir du moment ou tu utilises un timer, tu fais du multithread. =p
Voici un code qui pourrait t'aider :
Pour expliquer rapidement, ici, on fait un Timer (System.Timers en l'occurence), on lui assigne un callback qui instanciera la form suivante et nettoiera le timer et la premiere Form. J'assigne la propriété SynchronizingObject de Timer à la form actuelle pour ne pas avoir à invoquer dans le callback, dans un timer c'est un thread du pool qui s'occupe de l'elapsed, et le fait d'assigner cette propriété evite d'avoir à invoquer puisque ce n'est plus un thread du pool qui fait le boulot mais le thread du SinchronizingObject (donc le thread de la form ici).Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24public partial class Form1 : Form { //Interval à 50 secs System.Timers.Timer myTimer = new System.Timers.Timer(50000); public Form1() { InitializeComponent(); myTimer.Elapsed += delegate { //Une fois le timer fini, on instancie la nouvelle form Form2 f = new Form2(); f.Show(); //Et on dispose le timer et la premiere form myTimer.Dispose(); this.Dispose(); }; //On fait en sorte que le callback du timer se fasse sur le thread du Control myTimer.SynchronizingObject = this; myTimer.Start(); } }
@StormimOn :
J'avais deja repondu sur un autre sujet, mais le probleme est que tu fais un show() sur un thread qui n'a pas de boucle de message (le thread du pool ici), donc ton show() retourne immediatement et le thread se termine, tu te retrouves avec une Form à moitié construite et sans thread pompant les messages : elle gele puis plante. Pour reprendre ton exemple, essaie le code :
ce code marche tres bien, nous avons bien deux forms sur deux threads differents. La surcharge d'Application.Run() prenant une form en argument s'occupe de rendre visible la form pas besoin de .Show().Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19public partial class Form1 : Form { public Form1() { InitializeComponent(); } private void button1_Click(object sender, EventArgs e) { ThreadPool.QueueUserWorkItem(Traitement); } private void Traitement(object o) { Application.Run(new Form2()); } }
Bref on peut tres bien instancier des Forms sur des threads distincts, cepedant un conseil (ca peut servir) : Eviter de créer un control sur un thread du pool, car ces derniers sont en MTA et c'est impossible de le modifier (enfin parait il qu'en 1.1 on pouvait), et le probleme est que vous risquez d'avoir des problemes si vous touchez à des boites de dialogues (openfiledialog et consorts), ou a la classe Clipboard par exemple. Essaie par exemple d'afficher un OpenFileDialog dans la form2 avec le code precedent, tu risques de te faire "insulter" par le debugger. =) De plus, les threads du pool sont background, et donc l'application s'arretant quand il n'y a plus de threads foregrounds, cela peut etre embettant.
Donc pour revenir au probleme de l'OP, AMHA, la bonne facon de faire serait quelque chose dans le genre :
Ici on a bien deux forms distincts, ainsi que deux threads distincts (et foreground) gerant chacun une form.Code:
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
38public partial class Form1 : Form { //On créé un timer de 2 secs System.Timers.Timer myTimer = new System.Timers.Timer(2000); public Form1() { InitializeComponent(); myTimer.Elapsed += new System.Timers.ElapsedEventHandler(myTimer_Elapsed); myTimer.Start(); } void myTimer_Elapsed(object sender, System.Timers.ElapsedEventArgs e) { //On créé un second thread qui sera le thread de presentation de notre deuxieme form Thread secondThreadGUI = new Thread( delegate(object state) { //Nota : On est dans un thread du pool ici puisqu'on n'a pas assigné //la propriété SynchronizingObject du timer //On dispose le timer et ... myTimer.Dispose(); // ... on invoque async le thread de la premiere form pour qu'elle se termine this.BeginInvoke(new MethodInvoker(Dispose)); Form2 f = new Form2(); //On lance une boucle de message sur le thread courant (secondThreadGUI donc) Application.Run(f); }); //On le passe en STA (uniquement avant le lancement du thread) //Cela fait exactement la meme chose que [STAThread] sur la method Main secondThreadGUI.SetApartmentState(ApartmentState.STA); //On le passe en thread foreground secondThreadGUI.IsBackground = false; secondThreadGUI.Start(); } }
Bon courage.
OK, merci beaucoup pour toutes les réponses données :D
Je termine de toute manière mon projet avec le timer, en me servant du code donné par SirJulio, même si je n'ai pas tout bien compris, mais là je n'ai pas trop le temps, je regarderais quand je pourrais,...
Encore Merci
PS: je ne mets pas résolu par précaution, en effet cela m'oblige à regarder ce que contient ce fil de discussion,...
Mais si cela n'est pas bon pour les admin, surtout qu'il me le dise, je le mettrais aussitôt :)
Bon ,j'ai lu le long et très intéressant message de SirJulio,...
Et , j'ai quelques questions sur des trucs que je n'ai pas bien compris, si ça ne gênes pas.
D'abord, qu'es-ce-que le thread du pool (hypothèse: c'est le thread qui s'occupe de l'affichage)
Ensuite, qu'est ce que la propriété Elapsed du timer, et pourquoi lui assigne t'on une fonction avec un += (je pense que c'est pour préciser que l'on garde le(s) ancienne(s) fonction(s) qu'elle remplissait, mais qu'on en rajoute,...)
De plus, qu'est ce que ce callback auquel je ne comprends rien,...
Merci SirJulio, pour tous les codes que tu as bien voulu nous donner, et pourrais tu s'il-te-plaît répondre aux questions du débutant que je suis,...:?
Salut Hurin,
en fait la plupart de mon post ne t'etait pas forcement destiné, mais c'etait une reponse concernant l'instanciation de form sur des threads differents.
Je vais essaiyer de repondre a tes questions :
Pour le thread du pool, en fait, c'est un thread comme un autre mais qui emane d'un pool qui est unique dans ton application et qui est representé par la classe ThreadPool (System.Threading). Cette derniere gere des threads en interne, et te permet de poster simplement des taches dedans (.QueueUserWork(WaitCallback()) )sans te preoccuper de la gestion du thread. Le comportement que je voulais souligner ici est que les pools du threads (tu verras plus tard qu'on en a utilisé un implicitement) n'ont pas forcement les caracteristiques necessaires à gerer un affichage (car les threads ont des caracteristiques qui leur sont propres), et que le probleme est que les threads du pool sont moins parametrables qu'un thread créé specialement pour l'occasion. bref je ne t'etouffe pas plus sous les details. =p
Pour en revenir à cette ligne :
En fait le += est du à la conception des event sous c#. Je ne sais pas si tu es familier des délégués, mais un rappel à tout hasard. Un délégué est une variable qui represente une ou plusieurs fonctions qui ont un commun la signature du délégué. Un event est tres proche d'un délégué, donc en fait dans un event on peut stocker des methodes et les appeler en appelant le délégué. Ici Elapsed de l'objet Timer n'est pas une propriété, mais un evenement, et tu peux lui rattacher des fonctions ayant la meme signature que le délégué sous-jacent de l'event (qui sont des concepts assez proche pour rappel). Un event est appelé à un moment donné par la classe qui gere cette event (ici Timer), en se referant à ta doc, tu verras ici qu'elapsed est lancé quand le timer est fini. Et dans la syntaxe C# pour ajouter une methode à un event, on utilise += (pour info A += B est equivalent à A = A +B) car en fait un event ou un delégué perso, peuvent avoir une multitude de methodes rattachées, elles seront appelées les unes apres les autres quand tu declencheras ton event (ou que tu appelleras ton délégué). Voila pourquoi on utilise += pour etre sur d'ajouter et pas de remplacer.Code:myTimer.Elapsed += new System.Timers.ElapsedEventHandler(myTimer_Elapsed);
Un callback est en fait la methode qui sera appelée quand l'evenement sera lancée, ici, dans le troisieme code de mon precedent post, le callback c'est ca :
Quand le timer sera ecoulé il enclenchera son event Elapsed, et appellera la methode ci-dessus (qui créera un nouveau thread pour insticiera une nouvelle Form). Il appelle cette methode car je l'ai rattaché ici à l'event Elapsed :Code:
2
3
4
5
donc pour rattacher la methode, j'instancie un nouveau délégué de type ElapsedEventHandler et dans le constructeur, je lui passe la methode a rappeler (d'ou 'Callback') qui doit avoir la meme signature que le délégué sous jacent et sans parenthése. Ici ElapsedEventHandler est de la formeCode:myTimer.Elapsed += new System.Timers.ElapsedEventHandler(myTimer_Elapsed);
donc ma methode doit etre de la meme forme ( void X(object sender, ElapsedEventArgs e) ), et ca tombe bien c'est le cas (=p). Derniere chose tu peux aussi voir ceci :Code:public delegate void ElapsedEventHandler(object sender, System.Timers.ElapsedEventArgs e)
En fait c'est la meme chose, le compilateur fait instancié automatiquement le délégué dans le premier cas, et t'insulte si la methode n'a pas la bonne signature.Code:
2
3
4
Voila, en esperant, que ce soit plus clair, mais ne t'inquietes pas si cela te parait quelque peu esoterique pour le moment, le délégués, events et autres joyeuseté, ne sont pas vraiment simples à apprehender.
Bon courage. =)