Version imprimable
Bonjour,
J'ai un bouton Démarrer et un bouton Arrêter.
Quand je clique sur mon bouton démarrer, un traitement s'exécute. (Connexion a 2 bds pour la copie d'une table d'une BD à l'autre, etc...)
Une fois que je clique sur le bouton Démarrer ma fênetre gèle et il m'est impossible de cliquer sur Arrêter pour interrompre le traitement jusqu'attend que la copie de toutes les tables soit faite.
Comment puis laisser ma fenêtre active?
Merci
Tu devrais éssayer le BackgroundWorker, cf:
http://glarde.developpez.com/dotnet/bgworker/vb/
Plus précisément: quand on clique sur Démarrer tu fais exécuter le traitement par le BackgroundWorker. Ca exécute dans un nouveau thread, donc ça ne gèle pas ta form. Quand on clique sur arrêter, tu dis au BackgroundWorker d'arrêter le traitement.
Exemple avec un traitement bidon (c'est en C#, mais tu dois pouvoir traduire en VB.NET sans trop de mal...
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
38
39
40
41
42
43
44public partial class Form2 : Form { private BackgroundWorker worker; public Form2() { InitializeComponent(); worker = new BackgroundWorker(); worker.DoWork += new DoWorkEventHandler(Traitement); worker.WorkerSupportsCancellation = true; worker.RunWorkerCompleted += new RunWorkerCompletedEventHandler(worker_RunWorkerCompleted); } void worker_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e) { MessageBox.Show(e.Result.ToString()); } private void btnStart_Click(object sender, EventArgs e) { worker.RunWorkerAsync(); } private void btnStop_Click(object sender, EventArgs e) { worker.CancelAsync(); } private void Traitement(object data, DoWorkEventArgs e) { // traitement bidon... StringBuilder sb = new StringBuilder(); // On vérifie si la fin du traitement a été demandée while (!worker.CancellationPending) { sb.Append("x"); Thread.Sleep(100); } e.Result = sb.ToString(); } }
Merci à vous deux!
Mais si j'ai bien compris, chaque fois que je veux modifier un élément de l'interface(label, textbox, listbox, progressBar, infoBar,etc.) je dois le faire dans un nouveau thread? Si il y a un autre moyen, je serais bien content de l'apprendre, car ma fenêtre contient au moins une 10 d'élément à modifier...
J'ai beaucoup de mal à comprendre la relation entre ce que tu décrits là et ton premier poste. Tu peux préciser ????Citation:
Envoyé par Subkill
Oui bien sur:
Quand je clique sur démarrer, la copie de la bd1 vers la bd2 s'effectue. Mais j'indique dans un barre d'information l'état d'avancement de la copie, ainsi qu'avec une barre de progression. Aussi pour chaque copie de table, son nom s'ajoute dans un listbox. (voir la pièce jointe)
Depuis que j'ai rajouter le Backgroundworker pour exécuter mon traitement, chaque fois que je veux modifier l'interface, je recois le message suivant:
"Cross-thread operation not valid: Control 'lblCopie' accessed from a thread other than tje tjread it was created on."
Je dois alors créer un nouveau thread pour chacune des modifications à l'interface.
Non, pas vraiment... en fait le seul thread qui a le droit de modifier les éléments de l'interface graphique est celui qui a créé la Form. D'après la doc:Citation:
Envoyé par Subkill
Autrement dit, ton traitement ne doit pas modifier directement la Form, mais il peut dire au thread de la Form de le faire, via les évènements ProgressChanged (en appelant ReportProgress en cours de traitement) et RunWorkerCompleted (quand le traitement est fini). Dans les handlers de ces évènements, tu peux modifier les éléments de l'interface car ils sont exécutés dans le thread de la Form.Citation:
You must be careful not to manipulate any user-interface objects in your DoWork event handler. Instead, communicate to the user interface through the ProgressChanged and RunWorkerCompleted events.
Wouins, c'est ça que j'avais compris. Malheureusement cette solution n'est pas intéressante, puisque je ne contrôle pas les événements ProgressChanged et RunWorkerCompleted.
Je vais rester avec la création de nouveau thread, c'est plus long, mais je vais avoir le plein contrôle de mon application.
Merci encore
Si, justement, c'est toi qui génère ProgressChanged dans le code de ton traitement. RunWorkerCompleted est automatiquement déclenché quand le traitement est terminée.
Je résume:
- tu crées un BackgroundWorker, appelons-le "worker"
- tu crées un handler pour l'évènement DoWork, c'est là-dedans que se fait le traitement. L'évènement DoWork est déclenché quand on lance le traitement en appellant la méthode worker.RunWorkerAsync
- tu crées un handler pour l'évènement ProgressChanged, dans lequel tu mets le code de mise à jour de l'UI (par exemple, faire avancer une ProgressBar). L'évènement est déclenché quand le code du traitement appelle la méthode worker.ReportProgress
- tu crées un handler pour l'évènement RunWorkerCompleted, dans lequel tu mets le code à effectuer quand le traitement est terminé. Cet évènement est terminé quand le handler de l'évènement DoWork se termine.
C'est toi, dans la boucle de ton traitement, qui indique à l'UI qu'elle doit se mettre à jour, en appelant worker.ReportProgress. Il faut juste penser à mettre la propriété worker.WorkerReportsProgress à true, sous peine de InvalidOperationException...
Pour pouvoir interrompre le traitement avant la fin, il faut mettre worker.WorkerSupportsCancellation à true. A partir de l'UI, tu appelles worker.CancelAsync pour demander au traitement de s'arrêter. Ca met la propriété worker.CancellationPending à true. En testant cette propriété dans la boucle de ton traitement, tu peux l'interrompre (ce n'est donc pas instantané, ce qui permet à la procédure de traitement de se terminer "proprement").
Voilà, c'est à peu près tout je crois... j'espère que c'est plus clair ;)
Gérer toi meme le thread ne règlerais pas le probleme bien au contraire.
Car si ton thread modifie les propriété de l'ui... tu aurais quand meme une cross thread exception.
En plus en créant ton thread tu aura une série de chose à faire...
Soit le thread est créé dans le corps de ta classe Form... (tu l'isole pas dans une classe séparée... ce qui serait normallement préférable)
et dans ce cas tout changement de propriété doit se faire par Control.Invoke
(genre this.Invoke(....))
Car le workground process synchronise et le fait pour toi... mais si tu fait tes threads à la dure... faut tout gérer de A à Z.
Cependant il y a un cas où le backgroundworker n'est pas adapté...
Dans le cas où tu programme "proprement"... et où tu sépare bien les responsabilités, en gros les traitements surtout sur des BD n'ont absolument rien avoir dans le code de l'interface graphique... car dans ce cas ces traitements devraient se situer dans des classes dédiés, avec leurs propre gestion des threads (TheadPool par exemple)
cette écriture bien que plus hardue et complexe à le mérite d'etre beaucoup plus propre et permet de déboguer beaucoup plus vite... car on sais aussitot où chercher... ca permet également une maintenance plus simple.
voir la tonne de sujets qui traite des architectures N-Layers.
Le fait que ces composants existent signifie pas non plus
Je crois avoir un peu mieux compris. En tout ce que je suis sur d'avoir compris c'est que j'en ai encore beaucoup à apprendre et que cela va améliorer nettement la maintenance de mes applications.
Je vais essayer ça!
Merci et bonne journée