Bibliothèque: Calendrier - page 2

[Stanislav Korotky]

fxsaber:

Dans tous les calendriers HTML (y compris le calendrier standard et dans Terminal), le triple (Réel, Prévision, Précédent) = (Réel, Prévision, Révisé). Par conséquent, vous ne pouvez pas utiliser le champ Révisé dans l'historique avant que le prochain événement correspondant ne se produise. Les autres peuvent être utilisés.

Je n'ai pas travaillé avec l'API du calendrier local - sa documentation laisse à désirer (il faudrait donc une bibliothèque plus logique). N'est-il pas possible d'interroger un tableau de changements d'événements à partir de l'identifiant de changement spécifié ? Ce n'est pas basé sur le temps pour une raison quelconque. Malheureusement, ces questions concernent plutôt le calendrier lui-même et non la bibliothèque, mais comme la bibliothèque est au-dessus du calendrier, elles restent ouvertes pour elle aussi. Le problème avec les changements est que dans ma pratique passée d'utilisation de calendriers externes, j'ai remarqué que certains champs peuvent être ajustés rétroactivement, pour ainsi dire, et c'est pourquoi nous avons besoin de tester en tenant compte de la chronologie des changements.

Je ne comprends pas comment previous=revised(la structure MqlCalendarValue comporte les 4 champs : actual, prev, revised, forecast) et pourquoi on ne peut pas utiliser revised sur l'historique - à mon avis, revised peut apparaître (si previous est revised) à n'importe quel moment entre la dernière publication d'un événement et la suivante, c'est-à-dire uniquement sur l'historique.

[fxsaber]

Stanislav Korotky:

Je n'ai pas travaillé avec l'API du calendrier local - sa documentation laisse à désirer (il faudrait donc une bibliothèque plus logique). N'est-il pas possible d'interroger un tableau de changements d'événements à partir de l'identifiant de changement spécifié ? Pour une raison quelconque, ce n'est pas lié au temps.

Chaque changement dans le calendrier a son propre identifiant de changement. Vous pouvez donc interroger tous les changements à partir d'un change_id spécifique jusqu'au change_id actuel.

Je ne comprends pas comment previous=revised(la structure MqlCalendarValue comporte les 4 champs : actual, prev, revised, forecast) et pourquoi vous ne pouvez pas utiliser revised on history - imho, revised peut apparaître (si previous est revised) à n'importe quel moment entre la dernière publication de l'événement et la suivante, c'est-à-dire uniquement dans l'historique.

Dans les calendriers, vous ne pouvez voir que trois champs pour un événement. Dans l'API, il y en a quatre. La valeur révisée est la valeur d'affinement la plus récente, qui peut survenir même une semaine après la réception de l'événement. C'est la raison de l'interdiction quelque peu logique d'utiliser la valeur révisée dans les backtests.

Je ne vois que des scénarios assez restreints d'utilisation pratique du calendrier. Si vous avez vos propres options, exprimez-les. Peut-être que la bibliothèque a une API qui n'est pas optimale pour vos scénarios. Dans ce cas, nous y réfléchirons.

Le sujet semble être assez nouveau.

[traveller00]

Les fonctions GMT sont présentes, mais elles ne semblent pas être utilisées. Je ne sais pas si elles sont nécessaires.

[fxsaber]

traveller00:
Les fonctions GMT sont présentes, mais elles ne semblent pas être utilisées. Je ne sais pas si elles sont nécessaires.

Elles sont laissées pour l'avenir. Puisque le calendrier est lié à l'heure du serveur, et peut être pris de l'extérieur.

[Aleksey Mavrin]

fxsaber:

Je vois les scénarios d'utilisation pratique du calendrier de manière assez étroite. Si vous avez vos propres variantes, exprimez-les. Peut-être que la bibliothèque a une API qui n'est pas optimale pour vos scénarios. Dans ce cas, nous y réfléchirons.

Le sujet semble être assez nouveau.

A en juger par la description des fonctionnalités du calendrier de MT, nous devrions écrire quelque chose comme Observer avec le suivi de tous les changements, et l'arrivée de nouveaux événements par abonnement, et les changements dans Actual, Revised.

Je pense que cela pourrait être pratique.

[fxsaber]

Aleksey Mavrin:

À en juger par la description des caractéristiques du calendrier MT, nous devrions écrire quelque chose comme Observer avec suivi de tous les changements, et l'arrivée de nouveaux événements sur l'abonnement, et les changements dans les valeurs de Actual, Revised.

D'un point de vue terminologique, je ne comprends pas.

[Andrey Khatimlianskii]

fxsaber:

D'un point de vue terminologique, je ne comprends pas.

https://refactoring.guru/ru/design-patterns/observer

[fxsaber]

Andrey Khatimlianskii:

https://refactoring.guru/ru/design-patterns/observer

Merci. Si nous parlons de OnCalendar, une sorte de simulation via le mécanisme change_id sera nécessaire.

Il est préférable de démontrer les scénarios d'application à l'aide d'un code schématique, bien entendu.

[Aleksey Mavrin]

fxsaber:

Merci. Si nous parlons de OnCalendar, il y aura une simulation via change_id-mechanism.

Vous parlez de la simulation des événements du calendrier, qui pourrait être introduite dans MT5 à l'avenir.

Je faisais référence au mécanisme d'abonnement aux événements d'intérêt, y compris le changement de révisé, puisqu'il peut changer à tout moment.

Si vous n'êtes pas familier avec le modèle de l'observateur, je vous recommande d'étudier le lien d'Andrei.

L'essentiel de l'idée est brièvement que, par exemple, j'ai besoin de connaître tous les événements relatifs à l'euro avec la mention "révisé" :

J'ai besoin de connaître tous les événements EUR dont l'importance est supérieure à 3 pour le trading. Je m'adresse à un fournisseur (un objet de la classe qui gère les abonnements et les alertes, également appelé éditeur, qui peut être unique), je m'abonne.

Ensuite, le fournisseur surveille lui-même tous les changements dans les événements qui m'intéressent et m'en informe (en appelant la méthode de traitement des événements avec les informations correspondantes).

[fxsaber]

Aleksey Mavrin:

L'essentiel de l'idée est brièvement que, par exemple :

J'ai besoin de connaître tous les événements EUR d'importance supérieure à 3 pour faire du trading. Je contacte un fournisseur (objet de la classe qui gère les abonnements et les alertes, également appelé éditeur, qui peut être unique), je m'abonne.

Ensuite, le fournisseur surveille lui-même tous les changements dans les événements qui m'intéressent et m'en informe (en appelant la méthode de traitement des événements avec les informations correspondantes).

Aucun objet personnalisé ne peut se contrôler lui-même sans un appel correspondant. En d'autres termes, l'utilisateur doit l'écrire dans son code. S'il l'a écrit, il effectue lui-même le traitement.

Le mécanisme change_id est très simple : vous exécutez la méthode Refresh. Ensuite, vous obtenez les données, ce qui et où a été mis à jour dans la liste d'événements que vous avez créée.

CALENDAR Calendar;

Calendar.Set(...); // Spécifiez une liste d'événements que vous souhaitez suivre.

if (Calendar.Refresh(...)) // Si un élément de la liste a été mis à jour, traitez-le comme vous le souhaitez.