Если мы успешно прошли все проверки, то сделаем последнюю попытку обойтись без обращения к торговому серверу. Сначала узнаем начальную дату, для которой доступны минутные данные в формате HCC.
Запросим это значение функцией SeriesInfoInteger() с модификатором SERIES_TERMINAL_FIRSTDATE и опять сравним со значением параметра start_date.
if(SeriesInfoInteger(symbol,PERIOD_M1,SERIES_TERMINAL_FIRSTDATE,first_date))
{
//--- there is loaded data to build timeseriesif(first_date>0)
{
//--- force timeseries build CopyTime(symbol,period,first_date+PeriodSeconds(period),1,times);
//--- check dateif(SeriesInfoInteger(symbol,period,SERIES_FIRSTDATE,first_date))
if(first_date>0 && first_date<=start_date) return(2);
}
}
プログラム（とプログラマー）にとって、「ない」と「できない」の違いは何でしょうか？
データの準備ができていない場合は、エラーになります。
あるいは、この情報も瞬時に入手できないから、表示されないのかもしれません。
そして、サーバーに「入り込む」ことを避けるため。
また、あなたは私たちの「読者」である...質問です。
データが準備 できているのに、なぜ時系列を構築するのか (CopyTime(symbol,period,first_date+PeriodSeconds(period),1,times)))?
その通り、そこにあるものをロードして 準備するのです。しかし、指標の任意の遅延がそれにハングアップするすべてのものとチャットを遅くするという事実のために - 我々はシリーズが呼び出し時に準備ができていない場合、指標でそう作った - 関数は、エラーを返すとデータの準備をINITIALIZEます。しばらくすると、エラーを返さなくなります。これが、あなたのログで起こっていることなのです。
MigVRN!
Chukchaはヘルプを読み直したが、あなたに同意することはない。
"その通り、そこにあるものをロード し、かつ準備する "のです。
これはあなたの憶測ですが...。
しかし、ヘルプによると、SERIES_TERMINAL_FIRSTDATEという 識別子を持つ関数SeriesInfoIntegerは
戻るべき。
series_terminal_firstdate
期間に関係なく、クライアント端末のシンボルによる履歴の最初の日付
何も用意してはいけないのです
端末の履歴にデータがある - 日付を取得する。
いいえ、"0 "が返されます。
新しい一日が始まり、また巡り巡って
データを用意し、作業する。150回「おかしい」と言えば、150回「どうしたらいいか」の答えが返ってくる。 仕事なんだから、自分を大事にしろ！」と。
ありがとうございます。でも、あらゆることが証明されなければならないことは、あなたもよくご存じでしょう。
SDは、データが存在するときに0を返すことは、自分たちの関数のエラーではないと考える。
もしそうなら、ドキュメントに書かなければなりません。
Mikalas:
すべき、すべきでない......そんな話ばかりです。さて、どのように機能するかは、ご自分の目で確かめてください :)
唯一納得できるのは、どのデータがAT ONCE（いつでも利用可能）で、どのデータがアクセス時に端末が用意するのかがよくわからないことです。
私は(!)任意の時系列データ（時間と価格、バー数、ENUM_SERIES_INFO_INTEGER 列挙、または 何か他のものを忘れたかもしれない）にアクセスするとき、データが一度に準備されていない ことを理解しています。
そんな事態を避けるために、ヘルプに書かれているのです。
mql5-programは任意のシンボルとタイムフレームのデータにアクセスできるため、必要なタイムフレームのデータがまだ端末に生成されていない、または必要な価格データがトレードサーバーと同期されていない可能性があります。 この場合、データ準備の待ち時間を予測することは困難である。
データの準備完了を待つサイクルを利用したアルゴリズムは、最適な解決 策とは言えません。この場合、唯一の例外はスクリプトで、イベント処理ができないため、他にアルゴリズムを選択することができないからです。カスタム・インディケータでは、このようなアルゴリズムや他の待機ループは、このシンボルのすべてのインディケータと他の価格データ処理の計算の停止につながるため、強く推奨さ れません。
Expert Advisorやカスタムインジケータでは、イベントベースの 処理モデルを使用する方が良いでしょう。イベント OnTick() や OnCalculate() の処理で、必要な時系列のデータをすべて取得できていない場合は、イベントハンドラを残して、次のハンドラ呼び出し時にデータにアクセスできるように する必要があります。
すべき、すべきでない......そんな話ばかりです。さて、どのように機能するかは、ご自分の目で確かめてください :)
唯一納得できるのは、どのデータがAT ONCE（いつでも使える状態）で、どのデータがアクセス時に端末が用意するのかがよくわからないことです。
私は(!)任意の時系列データ（時間と価格、バー数、ENUM_SERIES_INFO_INTEGER 列挙、または 何か他のものを忘れたかもしれない）にアクセスするとき、データが一度に準備されていない ことを理解しています。
そんな事態を避けるために、ヘルプに書かれているのです。
mql5-programは任意のシンボルとタイムフレームのデータにアクセスできるため、必要なタイムフレームのデータがまだ端末に生成されていない、または必要な価格データがトレードサーバーと同期されていない可能性があります。 この場合、データ準備の待ち時間を予測することは困難である。
データの準備完了を待つサイクルを利用したアルゴリズムは、最適な解決 策とは言えません。この場合、唯一の例外はスクリプトで、イベント処理ができないため、他にアルゴリズムを選択することができないからです。カスタム・インディケータでは、このようなアルゴリズムや他の待機ループは、このシンボルのすべてのインディケータと他の価格データ処理の計算の停止につながるため、強く推奨さ れません。
Expert Advisorやカスタムインジケータでは、イベントベースの 処理モデルを使用する方が良いでしょう。イベント OnTick() や OnCalculate() の処理中に、必要な時系列のデータをすべて取得できなかった場合は、イベントハンドラを終了して、次のハンドラ呼び出し時にデータにアクセスできるように する必要があります。
アンドリュー！
皆さんはどうかわかりませんが、私は長年、文書作成に携わってきました。
見てください、ドキュメントから、私(!?)が理解したように、次のようになっています。
1.ターミナルにシンボルのヒストリーデータ（SERIES_TERMINAL_FIRSTDATE という識別子を 持つ SeriesInfoInteger）があるかどうか確認してみましょう。
多分、論外ですが、ビルドと初期化の両方が何かあるのでしょう。
2.データなし（履歴の開始日を空で返す） - データをサーバーに取りに行く。
日付がある場合は、CopyTime(symbol,period,first_date+PeriodSeconds(period),1,times) という関数で指定した時間枠を構築します。
4.指定された日付で時系列の先頭をチェックします（SeriesInfoInteger(symbol,period,SERIES_FIRSTDATE,first_date)）。
ドキュメントに書かれています。
しかし、私は(!)ターミナルでシンボルごとに（時系列ではなく！！）履歴データを要求すると、それはEXACTLYにあります。
関数は "0 "を返します。
これはRIGHTだと思いますか？
しかし、私が(!)ターミナルでシンボル別（時系列ではありません！！）の履歴データを求めると、それはEXACTLYにあります。
の場合、この関数は "0 "を返します。
これはRIGHTだと思いますか？
データ（準備されていない）はディスク上にあります。データ（用意されたもの）は、隣のチャットにある場合もあります。しかし、インダイレクトを実行しているチャットには、用意されたデータはありません。したがって、エラーが発生します。正しいのです。でも、不便なんです :)
私自身、このような質問は好きではないのですが、隣接する文字のデータをインジケーターに 要求することは重要なことなのでしょうか？(ヘルプに書かれていることと、私の例 - インジケータがExpert Advisorとチャットの実行を遅くする方法を考慮に入れて).これらの困難をすべて回避することができるのです...。
データではなく、"FIRSDDATE "を求めているのですね。日付はたぶんあるのですが、エコノミーの関係でデータが欠落している可能性があります。今使われていないのに、なぜ全キャラクターのデータを汲み上げるのか。開発者は、ユーザーがそのデータにアクセスしたときだけデータを汲み上げるという合理的な道を選んだのです。これが通常のやり方です。端末で作業するあなたは、このことを知っていて、それに従って行動しなければなりません。
トレードに時間を費やすどころか、初歩的なことにこだわってしまい、時間を浪費してしまうのです。時間を惜しまない。:)
ロボットが取引してくれているのですが、今、家にいないので...。
そして、自分のトレードを向上させるためにインジケータが必要なのです :)
アンドレイ！
皆さんはどうかわかりませんが、私は長年、文書作成に携わってきました。
見てください、ドキュメントから、私(!?)の理解では、次のようになっています。
1.端末のシンボルに関するヒストリーデータ（SeriesInfoInteger、識別子SERIES_TERMINAL_FIRSTDATE ）があるかどうか見てみましょう。
多分、論外ですが、ビルドと初期化の両方が何かあるのでしょう。
2.データなし（履歴の開始日を空で返す） - データをサーバーに取りに行く。
日付がある場合は、CopyTime(symbol,period,first_date+PeriodSeconds(period),1,times) という関数で指定した時間枠を構築します。
4.指定された日付で時系列の先頭をチェックします（SeriesInfoInteger(symbol,period,SERIES_FIRSTDATE,first_date)）。
ドキュメントに書かれています。
しかし、私は(!)ターミナルでシンボルごとに（時系列ではなく！！）履歴データを要求すると、それはEXACTLYにあります。
関数は "0 "を返します。
これはRIGHTだと思いますか？
選択的にではなく、もっと注意深くドキュメントを読んでください。ディスクに履歴データがあっても、端末にとっては「間違いなくそこにある」わけではありません。この場合（インジケータからアクセスした場合）、関数はメモリ上の時系列キャッシュに対してのみ動作します。同期メモリアクセスが行われ、そこに準備された時系列がない場合は、（配列の最初の要素の）日付SERIES_FIRSTDATEは 返されないことを意味する。しかし、当然ながら、このリクエストによって、メモリへのタイムスケールのロードが準備される。
SERIES_TERMINAL_FIRSTDATE リクエストは、データベースの初期化およびサーバーとの同期に関連しているため、最初の呼び出しはいずれにしてもすぐには動作 しないでしょう。
原則として、SERIES_SERVER_FIRSTDATE を用いて必要な履歴を取得できることを確認する。つまり、履歴要求がX回繰り返されたとしても、端末が SERIES_SERVER_FIRSTDATEを介して 履歴の存在を確認 すれば、関連する時系列データの利用は時間の問題（m1データベースとサーバーの同期と時系列の生成） であることを意味します。