ライブラリ: カレンダー - ページ 2

[Stanislav Korotky]

fxsaber:

すべての HTML カレンダー（標準カレンダーと ターミナルを含む）では、トリプル (Actual, Forecast,Previous) = (Actual, Forecast,Revised) です。従って、次の対応するイベントが発生するまで、履歴の改訂フィールドを使用することはできません。他は使用できます。

私はローカルカレンダーAPIを使ったことがないのですが、そのドキュメントには不満が残ります。指定されたchange_idから始まるイベント変更の配列を照会することはできないのでしょうか？なぜか時間ベースではありません。残念ながら、これらの質問はカレンダーそのものに対するものであり、ライブラリに対するものではありませんが、ライブラリはカレンダーの上にあるので、同様にオープンなままです。 変更に関する問題は、私が過去に外部カレンダーを使用した際に、いくつかのフィールドがいわば過去にさかのぼって調整できることに気づいたことです。

previous=revised（MqlCalendarValue構造には、actual、prev、revised、forecastの4つのフィールドがある）と、履歴でrevisedを使用できない理由が理解できません。

[fxsaber]

Stanislav Korotky:

ローカル・カレンダーのAPIは使ったことがないのですが、そのドキュメントには不満が残ります（したがって、より論理的なライブラリが必要でしょう）。指定した change_id から始まるイベント変更の配列をクエリすることはできないのでしょうか？それは何らかの理由で時間的な制約がないからです。

カレンダーの各変更はそれぞれの change_id を持っています。ですから、特定の change_id から現在の change_id までのすべての変更を照会できます。

previous=revised（MqlCalendarValue構造体には、actual、prev、revised、forecastの4つのフィールドが あります）と、履歴でrevisedを使用できない理由がわかりません。

カレンダーでは、イベントのフィールドは3つしか表示されません。APIでは4つあります。Revisedは最新の絞り込み値で、これはActualを受信してから1週間後でも可能だ。これが、バックテストでRevisedの使用がやや論理的に禁止されている理由です。

私は、便利なカレンダーの使い方のシナリオをかなり狭く見ています。もし独自のオプションがあれば、声を上げてください。もしかしたら、そのライブラリには、あなたのシナリオに最適でないAPIがあるかもしれません。それなら、私たちが考えます。

このトピックはかなり新しいようだ。

[traveller00]

GMT機能はあるが、使われていないようだ。必要なのかどうかはわからない。

[fxsaber]

traveller00:
GMT機能はあるが、使われていないようだ。必要なのかどうか分からない。

将来のために残してあるのです。カレンダーはサーバーの時間に 拘束され、外部から取得することができるのですから。

[Aleksey Mavrin]

fxsaber:

私はカレンダーの便利な使い方のシナリオをかなり狭く見ている。もしあなた独自のバリエーションがあれば、声に出してください。 もしかしたら、ライブラリのAPIがあなたのシナリオに最適でないかもしれません。それなら、私たちが考えます。

このトピックはかなり新しいようです。

MTカレンダーの機能の説明から判断すると、すべての変更を監視するObserverのようなものを書くべきで、サブスクリプションによる新しいイベントの到着、Actualの変更、Revised 。

そうすれば便利だと思う。

[fxsaber]

Aleksey Mavrin:

MTのカレンダー機能の説明から判断すると、すべての変更、サブスクリプション上の新しいイベントの到着、およびActual、Revisedの 値の変更を監視するObserverのようなものを記述する必要があります。

用語的にはよくわからない。

[Andrey Khatimlianskii]

fxsaber:

用語的には理解できない。

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

[fxsaber]

Andrey Khatimlianskii:

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

ありがとう。OnCalendarについて話しているのであれば、change_idメカニズムによる何らかのシミュレーションが必要でしょう。

もちろん、回路図のコードでアプリケーションのシナリオを示す方がよいでしょう。

[Aleksey Mavrin]

fxsaber:

ありがとう。もしOnCalendarについて話しているのであれば、change_id-mechanismを介して何らかのシミュレーションが行われるでしょう。

カレンダーイベントのシミュレーションのことですね。

私は、Revised の変更も含め、関心のあるイベントへのサブスクリプションのメカニズムについて言及しています。

Observerパターンをご存じない方は、Andreiのリンクで勉強されることをお勧めします。

アイデアのエッセンスを簡単に説明すると、例えば次のようになる：

取引のために、重要度3以上のEURイベントをすべて知る必要がある。私はプロバイダー（サブスクリプションとアラートを管理する クラスのオブジェクトで、パブリッシャーとも呼ばれる。

そして、プロバイダー自身が、私が興味を持っているイベントのすべての変更を監視し、私に通知します（対応する情報を持つイベント 処理のメソッドを呼び出すことによって）。

[fxsaber]

Aleksey Mavrin:

アイデアの要点は簡潔に言えば、例えばこうだ：

取引のために、重要度3以上のEURイベントをすべて知る必要がある。プロバイダー（サブスクリプションとアラートを管理する クラスのオブジェクトで、パブリッシャーとも呼ばれる。

そして、プロバイダー自身が、私が興味を持っているイベントのすべての変更を監視し、私に通知する（対応する情報を持つイベント 処理のメソッドを呼び出すことによって）。

どのカスタム・オブジェクトも、対応する呼び出しなしに自分自身をチェックすることはできない。つまり、ユーザーがコードに書かなければならない。もしユーザーが書いたのであれば、ユーザー自身が処理を行うことになる。

Refreshメソッドを実行する。Refreshメソッドを実行すると、どこで何が更新されたかを、作成したイベント・リストから取得できる。

CALENDAR Calendar;

Calendar.Set(...); // 追跡したいイベントのリストを指定する。

if (Calendar.Refresh(...)) // リストから何かが更新された場合は、必要な処理を行う。