[C++/CLI] M�thode cyclique dans thread principal

Bonjour,

Je programme en C++/CLI et je n'ai pas trouv� de forum sp�cifique donc je poste ma question ici.

Comment peut-on lancer une m�tode cyclique du style while (true) ... dans un programme .net totalement manag� ? Ces m�thodes doivent-elles forc�ment �tre lanc�es dans des threads autre que le thread principal ? Sinon comment faire ?
J'aimerais qu'une fonction rafraichisse mon affichage en fonction de param�tres qui sont mis � jour dans une autre m�thode cyclique. Si je dois lancer d'autres threads, je serai oblig� de pass� par des delegate pour rafaichir mes contr�les.
Puis-je ma�triser le temps de cycle de mes fonctions cycliques (en gros faire du temps r�el) => m�thode affichage toutes les 100 ms et �valuation des param�tres toutes les 20 ms.

A vrai dire j'ai du mal � comprendre ton probl�me.

Ta probl�matique, ne provient en rien du fait que tu d�veloppe en C++/CLI.
A vrai dire "tout" ce qui est faisable en C++ natif avec mfc ou autre pour l'affichage (comme par exemple, prendre directement l'api windows � bras le corps pour les plus courageux...) l'est en C++/CLI avec winforms.

Tu ne pourras pas plus faire du temps r�el, qu'en C++ natif, n'oublie pas que dans des environnements multiusers, tu ne peux garantir que tu fera du temps r�el � 100%, a moins de mettre ton appli en TimeCritical, et m�me l�... tu fait pas du temps r�el.

Ensuite o� est le probl�me ? pourquoi faire une boucle cyclique dans ton thread principal d'affichage? en .NET ton thread principal d'affichage, ou le thread attribu� � chaque fen�tre est d�di�... il ne fait que ca et tu n'a plus aucun contr�le sur lui, puisqu'il entre dans la boucle de pompe des messages windows.
Pour que ton thread principal fasse un traitement particulier, toutes les n millisecondes (on peut d�j� difficilement garantir un timing en milliseconde, alors en nanosecondes, c'est totalement illusoire, que ce soit sous windows, ou sous linux) tu peux mettre un composant Timer dans ta winform et mettre le code � traiter � chaque �vent dans un delegate...

Sinon tu peux toujours utiliser des threads � cot�, des threads g�r�s par toi, ou des threads de pool, tout d�pend de l'usage... pour faire ce que tu veux, et si tu as besoin de rafraichir l'affichage ou d'interop�rer dessus, rien ne t'empeche d'appeler les m�thodes Invoke des controles winforms.

Franchement je ne vois pas r�ellement la probl�matique.
Attention toutefois, avec les contr�les Timer. Il existe 3 namespace fournissant chacun une implantation diff�rente des Timer, avec leurs avantages et inconv�nients.
- System.Windows.Form.Timer : ce timer utilise une alerte windows, ce qui fait que windows envoie un message � ton application, et ton thread principal y r�agit alors... la pr�cision de ce type de timer ne peut descendre en dessous de 55ms.
- System.Threading.Timer : ce timer utilise les threads de pool pour fonctionner. Cela signifie qu'a �coulement du d�lai, le delegate sera lanc� par un thread de pool et non ton thread principal... ce qui n�cessitera l'utilisation d'Invoke() sur ton affichage. Probl�me, ce type de Timer est tributaire de l'ordonnanceur windows, et les temps en millisecondes, sont estim�s et d�pendent essentiellement du bon vouloir de l'ordonnanceur windows, du coup tu peux avoir des d�rives cons�quentes en temps. G�n�rallement 1000ms ont tendances � ce transformer en 850 � 1150ms.
- System.Timers.Timer : ce timer utilise les threads mais n'est pas tributaire de l'ordonnanceur. Il est tr�s pr�cis, � la milliseconde pr�s, mais demeure toutefois ex�cut� dans un thread autre que le thread principal... il faut donc utiliser du Invoke pour interagir avec les controles fenetr�s winforms.

tu peux regarder ici dans la faq C++/CLI http://dotnet.developpez.com/faq/cpp...trolFromThread

Citation:

---

A vrai dire j'ai du mal � comprendre ton probl�me.

---

Mon probl�me provenait du fait que je ne comprenais pas bien la cons�quence de l'instruction de Application::Run(gcnew frmMainScreen());
Je me basais sur les connaissances que j'avais (appli non graphique) et pour moi l'habitude �tait de d�marrer avec un main(). Dans ce main je pouvais lancer des boucles et faire tourner mon prog en boucle.
Ton explication m'a permis de mieux comprendre la gestion des prog winform avec le d�marrage d'une boucle de message sur laquelle je n'ai pas de contr�le.

Citation:

---

il ne fait que ca et tu n'a plus aucun contr�le sur lui, puisqu'il entre dans la boucle de pompe des messages windows.
Pour que ton thread principal fasse un traitement particulier, toutes les n millisecondes (on peut d�j� difficilement garantir un timing en milliseconde, alors en nanosecondes, c'est totalement illusoire, que ce soit sous windows, ou sous linux) tu peux mettre un composant Timer dans ta winform et mettre le code � traiter � chaque �vent dans un delegate...

---

En fait, c'est �a que je voulais savoir. Et je passerai par les delegate pour ce qui est de la mise � jour de mon affichage ou �ventuellement par les m�thodes invoke des contr�les.

Merci pour l'explication tr�s claire des diff�rents timers. Le dernier type me suffit largement, si je peux obtenir une pr�cision de +/- 1 ms c'est amplement suffisant.

Puisqu'il est � pr�sent �vident que par "totalement manag�" du veux dire une application Windows Forms, la r�pose est simple:

Dans la boucle de ta fonction, longue, tu peux appeler Application::DoEvents(). Attention toutefois, cela introduit de la r�entrance, et peut n�cessiter de prot�ger ton code contre certains clics malheureux (notamment, il faut emp�cher le programme de quitter si l'op�ration longue est en cours, ou bien interrompre imm�diatement l'application...)