//+-------------------------------------------+intOnInit()
{
EventSetMillisecondTimer(200);
//-return(INIT_SUCCEEDED);
}
//+-------------------------------------------+intOnCalculate (constint rates_total,
constint prev_calculated,
constdatetime& time[],
constdouble& open[],
constdouble& high[],
constdouble& low[],
constdouble& close[],
constlong& tick_volume[],
constlong& volume[],
constint& spread[])
{
// Здесь ничего не делаем, нам не нужен в данном случае OnCalculatereturn(rates_total);
}
//+-------------------------------------------+voidOnTimer()
{
// Здесь расчёты, и вывод информации на график в виде графических объектов
}
判断しようとすることが可能です。
分なら、TimeCurrent()で最後のバーの時刻を比較すればいい。M1でなければ、iTime(_Symbol,PERIOD_M1,0)を聞いて、TimeCurrent()と比較すればよいでしょう。
BidまたはLast価格(シンボルによって異なる)を最後のバーのClose価格と比較することができます。現在のシンボルを直接SymbolInfoTickに問い合わせることができます。ビッドとラストに加え、ティックタイムもあります
ありがとうございます。少なくとも、何か問題が起こったときに、どこでどのようにバグを探せばいいのかについての情報はあります。
しかし、私は、すべて同じステータスをチェックするために埋め込まれた関数を必要とするか、より良いまだそれは逃したティックの数を格納するint _LastError、のようなフラグだろうと思う、それはOnCalculate()を呼び出すときに便利になる - 複雑な計算ですぐに戻り、記号ストリームを解放するために行うこと。
ありがとうございます。少なくとも、何か問題が起こったときに、どこでどのようにバグを探せばいいのかについての情報はあります。
しかし、私は、すべての同じ必要性、ステータスをチェックするために埋め込まれた関数、またはより良いまだ、それは逃したティックの数を格納するint _LastErrorのようなフラグになると思います、それはOnCalculate()を呼び出すときに便利です - 複雑な計算ですぐに戻り、シンボルストリームを解放するために行うこと。
を考え、思案し...。これは解決策ではありません。見逃したティックに関する知識はどうなるのでしょうか(Slavaは、インジケータはすべてのティックを受け取ることが保証されていると言っていますが、この事実は、MQLプログラムだけでなく、クライアント端末のすべての危険につながります)? いずれにせよ、これらのティックは収集・処理しなければなりません。つまり、ティックを見逃したら、次はそれが可能だとなぜ突然望むのでしょうか?- 悪循環に陥っている。
考えていたのは...新しいティックが来ると、その瞬間にインジケータのすべての操作や計算が中断され、標準のMQL関数は、その実行中に新しいティックが来ると、エラーを返すはずです ...他のタイプのプログラム(スクリプト、Expert Advisors)にはほとんど必要ありません。
そして、インジケーターの刻みの関連性をいろいろとチェックする--大げさに言えば、これでは解決になりません。
私たちは、#property tester_everytick_calculateフラグを含まないインジケータに、各ティックではなく、ティックパック受信に基づく計算モードを含めるというアイデアを持っています。
これにより、指標の処理速度が遅いという問題が抜本的に解決され、一部の指標ではティック毎の処理が保証される可能性が残されています。
私たちは、#property tester_everytick_calculateフラグを含まないインジケータに、各ティックではなく、ティックのパックを受信することに基づいて計算モードを含めるようにするアイデアがあります。
これにより、指標によっては1ティックごとの処理が保証される可能性を残しながら、指標の遅延問題を劇的に解決することができます。
では、そのようなデザインで、非常に高速なインジケーターができるようになるのでしょうか?
もしそうなら、これは素晴らしいニュースです。
私たちは、#property tester_everytick_calculateフラグを含まないインジケータに、各ティックではなく、ティックパック受信に基づく計算モードを含めるというアイデアを持っています。
これにより、指標の処理速度が遅いという問題を根本的に解決し、一部の指標については1ティックごとの処理を保証する可能性を残します。
また、多通貨の同期配列を取得する標準関数を作れば、本当のホリデーになりますね。
私たちは、#property tester_everytick_calculateフラグを含まないインジケータに、各ティックではなく、ティックのパックを受信することに基づいて計算モードを含めるようにするアイデアがあります。
これにより、指標によっては1ティックごとの処理が保証される可能性を残しながら、遅い指標の問題を抜本的に解決することができます。
グッドアイディア!
そして、できればデフォルトで#property なしで動作することが望ましいです。
それ以外に必要な人がいるならば、#propertyを 付けさせればいいのです。
しかし、もう一つの問題は、リアルタイムで、刻々と 変化することです。この場合、1ティック後に次のティックが来る前に計算をする時間があるか、ないかで、トレーディングソリューションは無関係になります(3つ目の方法はありません)。そのため、この問題を解決する正しい方法はただ一つ、現在の計算をすべて中断し、新しいティックが来たときにエラーを返すことです。そうでなければ、リアルタイムのことは忘れてもいい。今のダニは日に日に速くなり、先は長いので、現在で全てのダニをタイムラグなく処理することは不可能なのはもちろん、将来を見据えて計画する必要があります。
ティックをパックで受け取るソリューションは、リアルタイム性を必要としないのであれば、良いものであり、おそらくそれほど高価なものではありません(ただし、「昨日の」価格で動作する指標でEAがどのように動作するのかは不明ですが、気にしないでください)。
しかし、もう一つのタイプのタスクがあります。それは、リアルタイムで、刻々と 変化するタスクです。ティック受信後に推定を行う時間があるかないかで、トレードソリューションは無関係になります(第3の選択肢はありません)。そのため、この問題を解決する正しい方法はただ一つ、現在の計算をすべて中断し、新しいティックが来たときにエラーを返すことです。そうでなければ、リアルタイムのことは忘れてしまう。今のダニは日に日に速くなり、先は長いので、現在で全てのダニをタイムラグなく処理するのは不可能なのはもちろんですが、将来を見据えて計画することが必要です。
EAの指標の多くはクローズドバー[1]で動作するため、ティックをスキップしても問題ありません。ティックを使用する指標は実際にありますが、その数は多くありません。
また、スーパーティックが必要な場合、そのためのインジケータは必要なく、すべてExpert Advisorのコードに記述することができます。ですから、1ティックごとにインジケータの動作を遅くするのは合理的ではありません。
プロパティ tester_everytick_calculate" を待ちます。
EAの指標の多くはクローズドバー[1]で動作するため、ティックをスキップしても問題ありません。ティックを使用する指標は実際にありますが、その数は多くありません。
また、スーパーティックが必要な場合、そのためのインジケータは必要なく、すべてExpert Advisorのコードに記述することができます。ですから、1ティックごとにインジケータの動作を遅くするのは合理的ではありません。
"#property tester_everytick_calculate" を待ちます。