Среди программ для автоматического трейдинга можно выделить две большие категории: торговые роботы и индикаторы. Первые предназначены для совершения торговых операций на рынках, а вторые — для анализа котировок и выявления закономерностей в их изменении. При этом индикаторы могут использоваться непосредственно в роботах, образуя полноценную...
そう、よく覚えています。OnInitで偽の履歴のプリロードを 試みるのです。そこでもOnCalculateでも、100回繰り返されるループでもうまくいきませんでした。実際のところどうなのかわかりませんが、外見上はお約束の履歴読み込みがなく（遅延はあるにせよ）、最後まで不満の残る結果でした。
さらに、何度も応答が返ってくるケースもありました。
が、結局インジケーターの続きはなく、応答は沈黙していた。
繰り返しでサイクルを行う必要はありません。
インジケータであれば、OnCalculateで正しいシンボル-期間の要求を1回行う。失敗したらreturn(0)
必要なシンボル期間のティックの到着時間を取り、この時間を必要な期間の始まりに正規化し、必要なシンボル期間の最後のバー1本を尋ね、その時間をチェックします。次に、履歴のタイミング状況を聞く
お使いのコンピュータの処理速度やリソースの負荷によっては、100個以上のOnCalculateが通過することがあります。
あなたが言っているコードは、とても古いものです。でも、図解には向いている。しかし、インジケータからの履歴リクエストは待たずに実行されるため（ドキュメントに明記されている）、インジケータでのSleepは意味がないため、インジケータには向いていない。
土日でも履歴が残ります。
該当するシンボルの最後のティックの時刻でバーの構築を制御する
インジケータであれば、OnCalculateで必要な文字期間を1回だけ要求する。失敗したらreturn(0)
まあ失敗した時のreturn(false)は定番ですね。だから、そうしています。しかし、問題は、私の更なる計算が履歴の読み込みに成功した場合（そしてこのロジックは変更できません）、計算機能から失敗して戻った場合、それらが発生しないだけで、更なるグラフィックの構築は 必要な座標を取得できず、すべてがクラッシュしてしまいます。これを回避する方法 - まだ考えていないし、あまりにも何かを変更することを期待していません。今のところ、履歴がすべて読み込まれ、すべてのタイムフレームのすべてのタイムラインが構築され、return(false)のために計算が欠けることなくインジケータがほぼ即座に動作するか、履歴の一部が欠落し、コードがreturnで上位の関数に戻り、無限ループで欠けている履歴を要求しようとするが、何も 起こらないかのどちらか。私は単に3番目のバリエーションを拒否した - 返さずに - といくつかの計算が失敗し、グラフィックスの描画が不完全になります。
まだ少しタンクに残っていて、戸惑っています...。インジケーターのMQL-ロジックを整理して、ローカルヒストリーだけで動作するようにすれば、足りないヒストリーをダウンロード する必要がなく、そのために遅延に悩まされることもないのでは？または、Copyの いずれかの機能......処理に必要のない履歴の部分までダウンロードするために、どうしてもサーバーに問い合わせなければならないのですか？簡単に言うと、標準のインジケータはダウンロードすることなく、PC上の既存の履歴に即座に描画されます（Examplesフォルダのインジケータを検索したら、そこでCopyBuffer() だけを使っていて、全てではありません）．それとも、再開が見送られるのか？再開の目的は何ですか？
ありがとうございます。あなたの推薦を考えてみます - おそらく、それらは私にとって役に立つでしょう。
数時間、パソコンから遠ざかっていました。この間、異常事態が発生し、ロボットが大量のプリントを縫い始めるという事態が発生しました。その結果、ディスクは完全に目詰まりしてしまう。このため、端末は価格履歴をディスクに書き出すことができず、業務に支障をきたす。
このようなディスクの目詰まりを防がなければならないのです。フォルダへの書き込みを禁止するのも一つの方法です。つまり、常にディスクにログを残さずに生活することです。また、十分な空き容量が残っていない場合は、ログファイルを消去する方法もあります。
この問題を解決した人はいますか？
インジケータであれば、OnCalculateで必要な文字期間を1回だけ要求する。失敗したらreturn(0)
週末にインジケーターを走らせたい場合は？
タイマからOnCalculateを強制的に呼び出すだけ（配列をコピーして 参照渡しする形で、すべての松葉杖を使用）？
インジケーターのMQLロジックを整理して、欠落している履歴をダウンロード したり、それに伴う遅延を許容することなく、ローカル履歴のみで 動作させることは現実的でしょうか。または、Copyの いずれかの機能......どうしてもサーバーにアクセスしないと、処理に必要のないその履歴の部分までダウンロードできないのですか？
自分でキャッシュを作る（ファイルに書き 込む）こともできる。
この提案を受けたときは、もちろん首をひねりましたが、MQが時系列処理に対するアプローチを変更するのを待つよりは、本当に良いことだと思います。
数時間、パソコンから遠ざかっていました。この間、異常事態が発生し、ロボットが大量のプリントを縫い始めるという事態が発生しました。その結果、ディスクは完全に目詰まりしてしまう。このため、端末は価格履歴をディスクに書き出すことができず、業務に支障をきたす。
このようなディスクの目詰まりを防がなければならないのです。フォルダへの書き込みを禁止するのも一つの方法です。つまり、常にディスクにログを残さずに生活することです。また、十分な空き容量が残っていない場合は、ログファイルを消去する方法もあります。
この問題を解決した人はいますか？
183Gb！」。私のSSDのほぼ4/5に相当します。仮想マシン イメージはもっと少ない。せめて老後に読むものがあれば...。
面白半分で、慌てて自宅を確認すると、183GB！！とアゴをぶつけました。私のSSDのほぼ4/5に相当します。仮想マシン イメージはもっと少ない。少なくとも老後は読むものがある...。
PrintとAlertは潜在的に危険な機能 です。
Price=0.7235200000000001なぜ、そんなことをするのでしょうか？エラーなのか、それとも統一して出力調整すべきなのか。まあ、仮にPrintFormatや fprintで梳くとして、原理的に数値の表現として間違ってはいないのでしょうか。