Souhaits pour MT5 - page 51

 
Yedelkin:

Explication. Si un conseiller expert ne traite pas les ticks pour le symbole auquel il est attaché, la génération continue d'événementsNewTick pour ce symbole conduira à un débordement de la file d'attente des événements traités par ce conseiller expert.


https://www.mql5.com/ru/docs/runtime/running

Tous les événements générés par le terminal client s'empilent dans la file d'attente commune. Les événements sont donc traités les uns après les autres dans l'ordre où ils sont reçus. La seule exception est l'événement NewTick. S'il y a déjà un événement dans la file d'attente ou si l'événement est en cours de traitement, un nouvel événement NewTick n'est pas placé dans la file d'attente.

La file d'attente des événements a une taille limitée. Lorsque la file d'attente est pleine, les anciens événements sont supprimés sans être traités pour faire de la place aux nouveaux événements. C'est pourquoi il est fortement recommandé d'écrire des gestionnaires d'événements efficaces et de ne pas utiliser de boucles infinies (sauf pour les scripts qui gèrent un seul événement Start).

Документация по MQL5: Программы MQL5 / Выполнение программ
Документация по MQL5: Программы MQL5 / Выполнение программ
  • www.mql5.com
Программы MQL5 / Выполнение программ - Документация по MQL5
 
Rosh:

https://www.mql5.com/ru/docs/runtime/running

Le terminal client stocke tous les événements qui se produisent dans une file d'attente commune. De cette manière, les événements sont traités les uns après les autres dans l'ordre de leur réception. L'exception est l'événement NewTick. S'il y a déjà un événement dans la file d'attente ou si l'événement est en cours de traitement, un nouvel événement NewTick n'est pas placé dans la file d'attente.

La file d'attente des événements a une taille limitée. Lorsque la file d'attente est pleine, les anciens événements sont supprimés sans être traités pour faire de la place aux nouveaux événements. Pour cette raison, il est fortement recommandé d'écrire des gestionnaires d'événements efficaces et de ne pas utiliser de boucles infinies (l'exception concerne les scripts qui gèrent un seul événement Start).

Ainsi, la règle "un événement NewTick pour toute la file d'attente commune" est toujours valable, indépendamment de la présence/absence de la fonction OnTick() dans l'EA. Merci pour la clarification !

Il y a encore une question sur la désactivation du processus de génération de tick inutile dans le testeur.

 

Yedelkin:

Il reste à désactiver le processus de génération de tics inutiles dans le testeur.

Ne les traitez pas là et logiquement tout ira bien.

 
Interesting:

Ne les traitez pas là et logiquement tout ira bien.

Ce n'est qu'au premier coup d'œil que l'on peut dire que "tout sera OK". Je suppose que les tics dans le testeur sont générés de manière forcée, sur toute la période de test/optimisation. Êtes-vous d'accord ? Si c'est le cas, les ticks seront générés de manière forcée pour le symbole, auquel l'Expert Advisor est attaché, et qui (ticks) ne sont pas traités par cet EA. C'est-à-dire que, malgré l'absence de traitement des ticks pour ce symbole (votre suggestion), le testeur va perdre son temps à générer des ticks. S'il y a quelque chose que je ne comprends pas, je suis prêt à apprendre de nouvelles choses avec plaisir.

 
Yedelkin:

Eh bien, je vous le répète : le conseiller expert ne fonctionne pas du tout avec le symbole auquel il est attaché. Et il n'a pas besoin de suivre un SL et un TP sur ce symbole. C'est-à-dire que le conseiller expert n'a pas besoin de ticks sur ce symbole. L'EA n'est attaché au symbole que si nécessaire, car il doit être attaché au moins quelque part pour fonctionner.

Ahem... Et pourquoi devriez-vous tester le conseiller expert sur un symbole sur lequel vous ne négociez pas ? Faites des essais sur celui sur lequel vous devez faire des échanges.

Et si vous n'avez pas besoin de négocier du tout, vous n'avez pas non plus besoin de tester - travaillez avec l'historique des cotations de l'EA fonctionnant en temps réel.

 
Rosh:

Le terminal client stocke tous les événements qui se produisent dans une file d'attente commune. De cette manière, les événements sont traités les uns après les autres dans l'ordre de leur réception.

Rashid, que se passe-t-il avec les événements qui ne sont pas traités par l'EA/script/indicateur ? C'était le sujet de la question.

Sont-elles réellement placées dans la file d'attente et ne sont-elles retirées de celle-ci que lorsque le traitement de l'événement auquel la réponse est destinée est activé ?

Ou ai-je encore raison de supposer que chacun a sa propre file d'attente, et que seuls les événements qui doivent être traités y sont rassemblés ?

Документация по MQL5: Основы языка / Функции / Функции обработки событий
Документация по MQL5: Основы языка / Функции / Функции обработки событий
  • www.mql5.com
Основы языка / Функции / Функции обработки событий - Документация по MQL5
 
Yedelkin:

Ce n'est qu'à première vue que "tout sera OK". Je suppose que les ticks dans le testeur sont générés de force, pendant toute la période de test/optimisation. Êtes-vous d'accord ? Si c'est le cas, les ticks seront générés de manière forcée pour le symbole, auquel l'Expert Advisor est attaché, et qui (ticks) ne sont pas traités par cet EA. C'est-à-dire que, malgré l'absence de traitement des ticks pour ce symbole (votre suggestion), le testeur perdra son temps à les générer. S'il y a quelque chose que je ne comprends pas, je serai heureux d'apprendre de nouvelles choses.

Parlons du mode "Tous les tics".

Je comprends qu'ils ne sont pas simplement générés de force, et que tous les symboles sont sélectionnés et négociés dans le conseiller expert (impossible sans lui).

Les ticks sur le symbole sélectionné dans les paramètres du testeur (symbole principal) peuvent être traités dans OnTick ou non (dans ce cas, si ce type d'événement est déjà traité ou existe dans la file d'attente, il n'y est pas ajouté).

Du moins, c'est ainsi que j'ai compris la logique du développeur.

Sur la base de la tâche que vous avez décrite, nous obtenons des informations sur les ticks sur les symboles supplémentaires avec les événements personnalisés, relatifs au ChartEvent. Le ChartEvent est placé dans la file d'attente et sera soit exécuté, soit supprimé lorsqu'elle sera pleine.

En partant de ce qui précède, il est clair que si le traitement des ticks provenant de "symboles supplémentaires" (externes à l'Expert Advisor) est effectué de manière inefficace, c'est le traitement des ChartEvent qui posera problème et qui encombrera toute la pile de la file d'attente des événements.

Il se peut que je ne comprenne pas entièrement la logique de votre Expert Advisor, mais dans ces conditions, je mettrais dans un timer un bloc pour collecter les informations sur les prix de tous les symboles et d'autres informations importantes sur des symboles supplémentaires. Et en utilisant ChartEvent, je ne transférerai que les informations relatives à l'apparition, par exemple, d'une nouvelle barre.

Vous pouvez également traiter les informations concernant d'autres symboles dans le bloc OnTick (s'il est utilisé), comme cela se fait dans MT4. Mais le timer présente ici un certain avantage, car il est traité périodiquement et pas plus d'une fois par seconde.

Документация по MQL5: Стандартные константы, перечисления и структуры / Константы графиков / Типы событий графика
Документация по MQL5: Стандартные константы, перечисления и структуры / Константы графиков / Типы событий графика
  • www.mql5.com
Стандартные константы, перечисления и структуры / Константы графиков / Типы событий графика - Документация по MQL5
 
komposter:

Rashid, qu'arrive-t-il aux événements qui ne sont pas traités par l'EA/script/indicateur ? C'était la question, n'est-ce pas ?

Sont-elles réellement placées dans la file d'attente et n'en sont-elles retirées que lorsque le traitement de l'événement auquel la réponse est destinée est activé ?

Ou ai-je encore raison de supposer que chacun a sa propre file d'attente, et que seuls les événements qui doivent être traités y sont rassemblés ?

D'après ce que je comprends, s'il n'y a pas de traitement, les événements dans la file d'attente sont "abandonnés" lorsqu'un nouvel événement arrive (si la file d'attente est pleine).
 
komposter:

Rashid, qu'arrive-t-il aux événements qui ne sont pas traités par l'EA/script/indicateur ? C'était la question, n'est-ce pas ?

Sont-elles vraiment placées dans une file d'attente et n'en sont-elles retirées que lorsque le traitement de l'événement pour lequel la réponse est fournie est activé ?

Ou ai-je encore raison de supposer que chaque file d'attente a la sienne, et que seuls les événements qui doivent être traités y sont collectés ?

Réponse des développeurs :

Chaque conseiller expert/script/indicateur a sa propre file d'attente. Bien entendu, rien dans la file d'attente n'est gelé si le gestionnaire n'est pas disponible. S'il n'y en a pas, on le lit et on le passe.

 
komposter:

Ahem... Pourquoi tester un EA sur un instrument que vous ne négociez pas ?

Vous n'avez probablement pas lu très attentivement mes posts, qui ont déjà exposé le principe de fonctionnement. Je suggère de clore le sujet à ce stade.

Je veux expliquer pourquoi je l'ai fait, mais en tout cas, merci.