Discussion :

[peter27x]

Bonjour,

je bosse sur Delphi depuis peu, après plusieurs années de powerbuilder.

Je recherche un équivalent Delphi de la fonction yield() de powerbuilder qui permettait de rendre la main à la machine lors d'un traitement long par exemple (boucle while, etc...).

Je ne retrouve pas cette fonction sous Delphi, y a t'il un équivalent ?

Merci.

[Cl@udius]

Salut

je pense que ce doit être:

Code :

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

Application.ProcessMessages;

@+ Claudius

[peter27x]

Salut

je pense que ce doit être:

Code :

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

Application.ProcessMessages;

@+ Claudius

Salut, après lecture de l'aide sur cette fonction, je me demande si cela correspond bien, car elle semble bloquer le traitement le temps que l'OS ait lu et traité les messages en attente.

Ensuite, du coup, j'ai regardait TApplication.HandleMessage, qui fait pareil mais que pour le dernier message en attente.

Mais ce n'est peut-être qu'une vue de l'esprit qui me fait croire que yield() fonctionne différemment.

[Cl@udius]

Sous PowerBuilder quel est le rôle exact de Yield ?

Et dans quel contexte l'utilise-t-on ? Laisser la possibilité à l'utilisateur d'interrompre un traitement long, dans une boucle par exemple.

[peter27x]

Sous PowerBuilder quel est le rôle exact de Yield ?

Et dans quel contexte l'utilise-t-on ? Laisser la possibilité à l'utilisateur d'interrompre un traitement long, dans une boucle par exemple.

C'était un collègue qui avait trouvé ça, du coup je l'utilisais, mais n'avais pas été à l'origine de la trouvaille... Je sais juste que par exemple, dans une while assez longue (en occurences) comportant des traitements assez lourds pour le CPU, on pouvait glisser par endroits des yield(), de manière à ce que l'utilisateur puisse, pendant le traitement, avoir quand même accès aux autres applications, même si bien evidemment c'était pas aussi fluide et aisé que lorsque le traitement en question ne tourne pas.

Ainsi, plutot que d'être bloqué avec le sablier et pas pouvoir cliquer ailleurs dans Windows, l'utilisateur pouvait prendre le contrôle de la souris, aller sur une autre appli, etc... Une sorte d'aide qui "forçait" le multi-tâche (un multi-tâche à l'ancienne presque !)

[Cl@udius]

A moins que d'autres avis viennent me contredire, je pense effectivement que le ProcessMessages doit être le plus proche de la fonction Yield().

Ainsi ton application continuera à recevoir les messages de Windows pendant ton traitement.

@+ Claudius

[ShaiLeTroll]

Il y a deux instructions !

Il y a Application.ProcessMessages, qu'il faut appeler réguilèrement (attention à l'interaction de l'application, je pense au Timer ou les traitements via Click, mieux vaut vérouiller les boutons durant un traitement long pour éviter des conflits), cela permet à ce que le programme en cours consulte la liste des messages à traiter, comme le fait de se dessiner (sinon l'application gèle et affiche un écran blanc, ce n'est pas bon signe pour un utilisateur surtout si il a découvert le CTRL+ALT+SUPR et qu'il croit que ça a planté donc il kill à mauvais escient ...), mais aussi les message clavier, souris, et les messages interne d'une application Delphi (TClientSocket asynchrone de D6 par exemple, ou la Méthode Form.Release), ... voir tout ce qui est lié à WndProc (WindowProc), c'est le coeur d'une application Windows ...

Il y a Sleep, qui force l'application à suspendre son traitement durant un laps de temps, et rend la main autre programme, il est a rappeler que de toute façon Windows prend la main à une application même si elle fait un traitement long accordant aux autres applications du temps pour bosser aussi ... en général, un appel à WaitMessage par une application est une bonne occasion pour le système pour reprendre la main ... c'est ce que fait la boucle Application.Run ainsi que Application.ProcessMessages, attention Sleep bloque tout traitement dans l'application, ce qui peut donner aussi l'impression d'un Freeze du programme (écran blanc, difficulté à recevoir le "focus" ...), ...

[Cl@udius]

Salut Shai

Je ne vois pas trop l'intérêt d'un sleep dans le cas présent.
Le sleep ne ferait que ralentir la durée du traitement, simplement en le suspendant. De plus, à ma connaissance, l'appli ne traite pas ses messages pendant le sleep.

Je ne pense pas qu'il y ait un réel équivalent de Yield et comme tu le dis Windows prend de toute façon la main sur une application quelque soit son état Idle ou non.

[Droïde Système7]

Salut les copains,

Peut-être s'agit-il d'un Sleep tout en dentelle et surtout non bloquant ; comme par exemple ici.

@+

[skywaukers]

Bonjour,

on peut aussi utiliser un thread pour y mettre un traitement long sans rien bloquer. Et si dans le thread il y a un traitement très gourmand en cpu, je ne vois pas poourquoi application.processmessage ne ferait pas l'affaire. D'ailleurs j'ai peur de ne pas avoir bien saisit la différence avec yield ..

@++
Dany

[JP.NUAGE]

Je n'ai pas la solution mais d'après ce que j'en ai compris, le yield provoque une sorte de mise en tache de fond (comme pour une impression) de l'application qui le contient : je ne vois pas bien comment le ProcessMessage pourait faire celà ! C'est juste un éléments de réflexion !

[anapurna]

salut

le processmessage laisse l'application respirer mais ce n'est pas pour autant
qu'elle arrete le traitement totalement en fait elle fait passer un message dans la queue de windows et ensuite il reprend la main

tu peut aussi utiliser doidle qui lui, en fait ne fonctionnne qu'a la reception d'un evenement et reactive l'application

@+ Phil

[ShaiLeTroll]

...
Je ne vois pas trop l'intérêt d'un sleep dans le cas présent.

, je ne faisais qu'expliqué les différentes fonctions d'interruptions de programme, je pensais qu'opposer Application.ProcessMessages qui consulte les messages et effectue les opérations nécessaires à un sleep qui met l'application véritablement en pause

...
Je ne pense pas qu'il y ait un réel équivalent de Yield et comme tu le dis Windows prend de toute façon la main sur une application quelque soit son état Idle ou non.

Sinon, cela vous arrive de consulter l'aide ?

The Yield function is obsolete. This function is provided only for compatibility with 16-bit versions of Windows. In the Win32-based application programming interface (API), this function does nothing.

Threads that contain windows should use the DispatchMessage, PeekMessage, or TranslateMessage functions. The message-loop functions handle message synchronization properly and yield at the appropriate times.
Threads that do not contain windows should use the Sleep function with a sleep time of zero milliseconds to give up the remainder of their current time slice.
Threads that create a process can use WaitForInputIdle to wait until the new process has finished its initialization.

See Also

DispatchMessage, PeekMessage, Sleep, TranslateMessage, WaitForInputIdle