Discussion :

[Plio]

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.

[cinemania]

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.

[nico-pyright(c)]

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

[Plio]

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.

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.

[Médinoc]

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:oEvents(). 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...)