voidOnStart()
{
datetime Arr[];
if(CopyTime(_Symbol,PERIOD_W1,0,1,Arr)<0) Print("Ошибка");
Print("Время открытия нулевого бара W1 = "+TimeToString(Arr[0]));
ArraySetAsSeries(Arr,true);
if(CopyTime(_Symbol,PERIOD_H4,0,100,Arr)<0) Print("Ошибка");
Print("1 "+"CurrentTime = "+TimeToString(TimeCurrent()));
int Res=Bars(_Symbol,PERIOD_W1,Arr[99],TimeCurrent()); // выполняется быстро Print("2 Время открытия 99 бара H4 = "+TimeToString(Arr[99])+" Номер бара W1= " +IntegerToString(Res));
Res=Bars(_Symbol,PERIOD_W1,Arr[0],TimeCurrent()); // выполнение происходит более 10 секунд!!! Print("3 Время нулевого бара H4 = "+TimeToString(Arr[0])+" Номер бара W1= " +IntegerToString(Res));
}
結果
2018.03.3023:39:31.079 BagBars (EURUSD,H4) Время открытия нулевого бара W1 = 2018.03.2500:002018.03.3023:39:31.079 BagBars (EURUSD,H4) 1 CurrentTime = 2018.03.3023:542018.03.3023:39:31.079 BagBars (EURUSD,H4) 2 Время открытия 99 бара H4 = 2018.03.0820:00 Номер бара W1= 32018.03.3023:39:47.176 BagBars (EURUSD,H4) 3 Время нулевого бара H4 = 2018.03.3020:00 Номер бара W1= 0
明らかにゼロ。
与えられた時間枠の中でバーがゼロと判断するのに22秒かかってもいいのでしょうか？
Barsの内部実装のアルゴリズム上のバグであることは明らかです。
それに、ある時間帯のバーがゼロと、このゼロを どう区別しているのか理解できない。
ドキュメントより：Bars()関数を呼び出す 際に指定したパラメータの時系列のデータがまだ端末に生成されていない場合、または関数呼び出し時に時系列データが取引サーバーと同期されていない場合、関数はゼロ値を返します。
つまり、Nullの結果とNullのエラーはどのように区別すればいいのでしょうか？それに、ある時間枠のバーがゼロとこのゼロを どう区別しているのかが理解できません。
ドキュメントより：Bars()関数を 呼び出したときに、指定したパラメータの時系列のデータがまだ端末に生成されていない場合、または関数を呼び出した時点で時系列のデータが取引サーバーと同期されていない場合、関数はゼロ値を返します。
この問題ではゼロの起源は重要ではなく、重要なのは、このゼロが数十秒という形で永遠にバーズ関数によって生まれるということです。
わからないのは、ある時間帯のバーがゼロと、このゼロを どう区別しているのかということです。
ドキュメントより：Bars()関数を呼び出す 際に指定したパラメータの時系列のデータがまだ端末に生成されていない場合、または関数を呼び出した時点の時系列データが取引サーバーと同期されていない場合、関数はゼロを返します。
つまり、Nullの結果とNullのエラーはどのように区別すればいいのでしょうか？考えてみてください。もし、Bars関数の類似品を作るという課題があり、配列datetimeが与えられたとしたら、その要素の値は数が増えるにつれて減少する、言い換えれば、配列はソートされていることになります。
このようなソートされた配列の要素数を、ある時間間隔で検索するアルゴリズムを実装することは難しいと思いますか？また、与えられた時間間隔にバーが1本もないか、配列がまだ初期化されていない場合は、ゼロを返すべきです。
いいえ、アルゴリズムはとてもシンプルです。22秒の間、何を走らせることができるのか？
この問題では、ゼロの起源は重要ではなく、重要なのは、このゼロがバーズ関数によって、数十秒という形で、何年もかけて生まれてくるということです。
正確には原点が重要で、もし ::Bars() がヒストリーエラーの 場合に 0 の代わりに -1 を返していれば、遅延は発生しないでしょうから。しかし、現在では0はエラーと解釈され、遅延は内部繰返しによるものであるhttps://www.mql5.com/ru/forum/1111/page2200#comment_6955559
さらに、追加のチェックを導入し、遅延がなくなったとします。では、どうなったのでしょうか。ゼロになりましたね。これは結果なのか、エラーなのか？
これは、履歴の読み込みが原因である可能性が高い
つまり、最初のPrintは遅延なく処理される、つまりH4までの履歴はすでに読み込まれているというのがおかしなところです。
また、CopyTime H4をW1に変更すると、全く遅延がなくなります。W1用の履歴もすでに読み込まれているということです。
ただ、CurrentTime()とゼロバーのオープン時間との 間の時間間隔によって、Barsが阻害されるのです。
なぜなら、もし ::Bars() がヒストリーエラーの 場合に 0 の代わりに -1 を返したら (現在と同じように)、遅延は全く発生しないからです。しかし、現在は0がエラーと解釈され、内部繰返しにより遅延が発生するhttps://www.mql5.com/ru/forum/1111/page2200#comment_6955559。
さらに、追加のチェックを導入し、遅延がなくなったとする。では、どうなったのでしょうか。ゼロになりましたね。これは結果なのか、エラーなのか？
ゼロの結果が、与えられた間隔でヒットしないバーであるか、そのような配列がないことであるかは、私のすべてのアルゴリズムにおいて重要ではありません。
問題から遠ざかっていますね。
問題点を取り上げていますね。
私は問題の本質を述べているのですが、あなたは自分の特殊なケースに固執しています。前の投稿から 判断すると、前のページで詳しく説明されていますが、遅延が発生するタイミング（原因以外の部分です）をまだ理解されていないようですね。
このスクリプトで理解できるかもしれません
私は問題の本質を述べているのですが、あなたは自分の特定のケースに焦点を合わせています。前のメッセージから 判断すると、前のページで詳しく説明されていますが、遅延が発生するタイミング（これは理由以外にもあります）をまだ理解されていないようです。
遅延が発生するタイミングについては、すでに上記で私の意見をまとめました。
もう一度言います。
start_time が要求された TF のゼロバーを開いた時刻から TimeCurrent() までの範囲にある場合、Bars はハングアップする。(あくまで仮説ですが、実践で確認)
はい、特殊なケースでエラーが発生します。しかし、プライベートケースは、プログラミング言語の標準的な組み込み関数にはないはずです。
そして、あなたの「ポイント」は、私がよく知っているバーズコマンドの文献を引用しているだけなので、ポイントではありません。Bars関数にはエラーコードが必要ないため、エラーコードはありません。
この場合、完全に形成された時系列のアレイを扱うのでなおさらである。
このことは、私のスクリプトのコードを少し修正したものを見ればよくわかる。
結果
このスクリプトが理解の助けになるかもしれません。
あなたのスクリプトは、この問題、つまりハングアップを実証しています。
開始時刻と停止時刻の時間範囲が週足バー内にあるため。
週刊誌のバーから外れたら、フリーズはない。
わかりやすい例をありがとうございました
MT4のCopyHigh, CopyLow機能（他は見ていない）において、テスターに履歴がない場合、重大なエラーが 発生する。EAはH1でテストされ、リクエストはM1からでした
1 15:14:35.410 2017.01.04 19:54:24 Access violation read to 0x0A971FE8 in 'C:\Users\Halyna\AppData\Roaming\MetaQuotes\Terminal\287469DEA9630EA94D0715D755974F1B\MQL4\Experts\____________.ex4'
3 15:14:35.465 2017.01.04 19:54:24 EAの重大なエラーのためテストパス停止