Discussion :

[Clorish]

Salut !

Je recherche un equivalent a ceci (code DElphi) :

Code :

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

1
2
3
4
5
 
Procedure TForm1.ApplicationOnIdle(Sender : Tobject; Var Done : Boolean);
Begin
Done := False;
End;

Ce code repond a l'evenement "OnIdle" de l"application et le parametre "done" passé a false permet de boucler sur ce gestionnaire tant que l'application est OnIdle.

J'ai bien trouvé le gestionnaire applucation.idle, mais je n'arrive pas a boucler dessus. Il ne s'execute qu'une seule fois par "idle".

J'ai aussi vue un bout de code basé sur la procedure PeekMEssage mais VS2005 Express n'en a pas connaissance

un tit coup de pouce ?

[theMonz31]

salut

beh, le principe du OnIdle, c'est de te prévenir que l'application n'a plus "rien"
à faire

En théorie, si on "bouclait" sur ce traitement, cela reviendrait à faire plein d'appel à une méthode qui dit qu'on ne fait rien... y aurait peut-etre un paradox

Donc, pour moi, le Idle Event de application ( attention à retirer le Handler d'evenement (conseil donné dans le msdn)), permet de savoir que l'application
n'a pas grand chose à faire.. donc, qu'on peut à l'occasion lancer un traitement
qui tire profit de ce manque d'activité de l'application

Apres , bouclé dessus me parait un "non-sens"... (enfin, jusqu'à ce qu'on m'explique la finalité d'un tel bouclage )

The Monz, Toulouse

[Clorish]

merci pour ta reponse mais en fait je percoit l'evenement OnIdle differement.
En fait c'ets Delphi, a l'aide de la fonction "done" me permet de tenir un tel raisonement.

L'evenement OnIdle est en effet utilisé pour avertir que l'application ne fait rien et ainsi lancer un traitement.
Or ce traitement peut etre long ... tres long ..... et donc necessite une interruption de temps a autre pour laiser l'application tourner.

Je dirais donc que ces traitements sont a executer "tant que" l'applciation est Idle.
D'ou l'interet de la variable Done, qui indique au systeme que le traitement n'est pas terminé et doit se poursuivre "tant que" l'applciation est ou redeviens Idle.

Un exemple conctret : Je cherche a mettre en place ce systeme pour effectuer le rendu 3D d'une scene Temps reel.
Sous Delphi, le gestionnaire OnIdle lance le rendu d'uen frame.
Une fois ce traitement effectué, l'applciation reprends ses droit et continue sont execution.
Si elle n'a rien a faire apres le rendu de la frame (ie file d'evenement vide) alors on relance le rendu et ainsi on enchaine les frames, sans bloquer l'application.

Tout ca pour en venir a la 2e partie de ma question precedente : Comment detecter que la pile d'evenement est vide (PeekMEssage ne marche pas chez moi :p) ou bien suspendre l'execution le temps d'executer les evenements de l'application

Note : Qu'entends tu par

( attention à retirer le Handler d'evenement (conseil donné dans le msdn))

[theMonz31]

salut

dans la doc du msdn, il conseille de faire un Application.Idle-=TonDelegate

car Application étant un élément static, la doc a l'air d'expliquer que, meme une fois l'application terminer, on aurait un bout de mémoire non rendu.. Ca me parait bizarre, mais c'est l'explication qui se trouve dans le msdn...

Pour moi, il n'est pas "judicieux", si tu parles de Rendu 3D de la faire dans le OnIdle

La logique (enfin la mienne), voudrait que le rendu soit fait dans un Thread à part .... et ainsi, tu n'aurais pas à te gérer l'état de la pompe à message windows à l'intérieur de ton rendu 3D...

Au pire, un Application.DoEvent() (dont je ne suis pas fan), peut te permettre de rendre la main pour que les messages systèmes soient traités

The Monz, Toulouse

[cinemania]

de toute facon ta variable done ne règle pas le probleme...

en effet, quand l'event OnIdle est déclenché, ton code appelant ton délégate est "bloqué" et ne peut récupérer le controle qu'une fois la procédure achevée...
Done n'a donc aucun sens puisque de toute facon tu bloque le controle de la file de message et tu ne récupère sa valeur que lorsque la procédure se termine. Alors peut importe la valeur de done à ce moment là, tu récupère le controle.... tu fait ce que tu as a faire et tu relance l'event OnIdle quand ta a nouveau plus rien en cours.
Le Done n'a un sens que si tu indique l'état d'un thread d'arrière plan, permettant ainsi de quitter ton délégate prématurément, mais dans ce cas ca n'a aucun sens car tu utilise deja une architecture multithreadé.

C'est peut etre pour cette raison que l'équivalent n'existe pas en C# non ? ce n'est pas parce que delphi propose un système qu'il est forcément "bon", surtout si une architecture multithread propose un système plus robuste.

Exemple: le gestionnaire mémoire intégré à tes appli natives compilées delphi/c++ builder, est une calamité sans nom et pourtant... il est tjs là, et ta pas le choix tu dois faire avec. (c'est pour cette raison que suis passé à autre chose que delphi d'ailleurs)

Récupérer l'OnIdle n'a de sens que si tu veux lancer un traitement dans un thread mais surtout pas sur le thread principal car celui ci ne reprendra pas la main temps que le traitement lourd ne sera pas fini, ce qui au final va nuir à ton application et rendra l'utilisation d'un OnIdle QUADUC, surtout que tu va freezer ton thread principal...

[Clorish]

je comprends le principe general, surtout pour y avoir reflechi a plusieurs reprises. Mais l'usage de thread est assez delicat.

PAr contre la ou je ne suis pas tout a fait d'accord avec vous, c'est sur l'utilsation du Idle.

bien sur que le systeme ne reprendra la mai nqu'apres le gestionaire executé. Or c'est une procedure gerant le rendu d'une frame.
A priori, pour conserver une qualitée correcte, il est quand meme conseiller qu'elle ne dure pas plus de 1/30e de seconde ... donc ne bloque pas l'application suffisement longtemps pour la paraliser.

Ensuite, sous delphi la variable Done permet simplement a systeme de savoir si on souhaite "arreter le traitement" ou le "reexecuter" tant que la file de message est vide et non d'interrompre le traitement.

En pratique, si Done = true, delphi execute une seule fois le gestionnaire entre chauqes sessions d'evenement : 1 Idle, Attente de messagesn traitement des messages, File Vide donc 1 appel a Ide.

Si done = false :
Idle, Idle, Message, Idle, Idel, Ide, Message, Message, Message, Idle, ....

j'ai vu sur certaisn forums que le gestionnaire Idle implemente une boucle while, tant que la file de message est vide, qui effectue le rendu d'une frame.
Donc des que la pile se remplie, il arrete son execution et se relance des que la pile est de nouveau vide.

Mais dans ce cas ... je n'arrive simplement pas a utiliser PeekMessage