Libraries: Calendar - page 2

[Stanislav Korotky]

fxsaber:

In all HTML calendars (including the standard one and in Terminal) the triple (Actual, Forecast, Previous) = (Actual, Forecast, Revised). Therefore, you cannot use the Revised field on the history until the next corresponding event occurs. The others can be used.

I haven't worked with the local calendar API - its documentation leaves much to be desired (so a more logical library would be needed). Isn't it possible to query an array of event changes starting from the specified change_id? It's not time-based for some reason. Unfortunately, these questions are more for the calendar itself and not for the library, but since the library is on top of the calendar, they remain open for it as well. The problem with changes is that in my past practice of using external calendars I noticed that some fields can be adjusted retroactively, so to speak, and that's why we need to test taking into account the chronology of changes.

I don't understand how previous=revised(MqlCalendarValue structure has all 4 fields: actual, prev, revised, forecast) and why you can't use revised on history - imho, revised can appear (if previous is revised) at any moment between the last event release and the next one, i.e. just on history.

[fxsaber]

Stanislav Korotky:

I haven't worked with the local calendar API - its documentation leaves much to be desired (hence a more logical library would be needed). Isn't it possible to query an array of event changes starting from the specified change_id? It's not time-bound for some reason.

Each change in the calendar has its own change_id. So you can query all changes from a specific change_id up to the current change_id.

I don't understand how previous=revised(MqlCalendarValue structure has all 4 fields: actual, prev, revised, forecast) and why you can't use revised on history - imho, revised can appear (if previous is revised) at any moment between the last event release and the next one, i.e. just on history.

In calendars you can only see three fields for an event. In the API, there are four. Revised is the most recent refinement value, which can come even a week after the Actual is received. This is the reason for the somewhat logical prohibition of using Revised in backtests.

I see rather narrowly scenarios of convenient calendar usage. If you have your own options - voice them. Perhaps the library has an API that is not optimal for your scenarios. Then we will think about it.

The topic seems to be quite new.

[traveller00]

GMT functions are there, but they don't seem to be used. I don't know if they are needed there.

[fxsaber]

traveller00:
GMT functions are there, but they don't seem to be used. I don't know if they are needed there.

They are left for the future. Since the calendar is bound to the server time, and can be taken from outside.

[Aleksey Mavrin]

fxsaber:

I see rather narrowly scenarios of convenient use of the calendar. If you have your own variants - voice them. Perhaps the library has an API that is not optimal for your scenarios. Then we will think about it.

The topic seems to be quite new.

Judging by the description of MT calendar features, we should write something like Observer with monitoring of all changes, and the arrival of new events by subscription, and changes in Actual, Revised.

Then I think it could be convenient.

[fxsaber]

Aleksey Mavrin:

Judging by the description of the MT calendar features, we should write down something like Observer with monitoring of all changes, and the arrival of new events on the subscription, and changes in the values of Actual, Revised.

Terminologically I do not understand.

[Andrey Khatimlianskii]

fxsaber:

Terminologically, I don't get it.

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

[fxsaber]

Andrey Khatimlianskii:

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

Thanks. If we are talking about OnCalendar, some kind of simulation via change_id mechanism will be.

It is better to demonstrate the application scenarios with schematic code, of course.

[Aleksey Mavrin]

fxsaber:

Thanks. If we are talking about OnCalendar, there will be some simulation via change_id-mechanism.

You are talking about simulation of calendar events, which may be introduced in MT5 in the future.

I was referring to the mechanism of subscription to the events of interest, including the change of Revised, since it can change at any time.

If you are not familiar with the Observer pattern, I recommend you to study Andrei's link.

The essence of the idea is briefly that, for example:

I need to know all EUR events with importance higher than 3 for trading. I apply to a provider (an object of the class that manages subscriptions and alerts, also called publisher, can be a single one), subscribe.

And then the provider itself monitors all changes in the events I am interested in and notifies me (by calling the method of event processing with the corresponding information).

[fxsaber]

Aleksey Mavrin:

The gist of the idea is briefly that, for example:

I need to know all EUR events of importance higher than 3 for trading. I contact a provider (object of the class that manages subscriptions and alerts, also called publisher, can be single), subscribe.

And then the provider itself monitors all changes in the events I am interested in and notifies me (by calling the method of event processing with the corresponding information).

No custom object can check itself without a corresponding call. I.e. it must be written by the user in his code. If he has written it, then he does the processing himself.

The change_id mechanism is very simple: you run the Refresh method. After that you get the data, what and where was updated in the list of events you have created.

CALENDAR Calendar;

Calendar.Set(...); // Specify a list of events that you want to track.

if (Calendar.Refresh(...)) // If something has been updated from the list, process it as desired.