2015.07.2320:48:13.449 Spread (BR-8.15,M1) OnCalculate: Не получены бары по символу BR-9.152015.07.2320:48:13.449 Spread (BR-8.15,M1) OnCalculate: Не получены бары по символу BR-9.152015.07.2320:48:13.449 Spread (BR-8.15,M1) OnCalculate: Не получены бары по символу BR-9.152015.07.2320:48:13.449 Spread (BR-8.15,M1) OnCalculate: Не получены бары по символу BR-9.152015.07.2320:48:13.449 Spread (BR-8.15,M1) OnCalculate: Не получены бары по символу BR-9.15
こんにちは、Anton!
アドバイスにしたがって(LoadServerData() は SeriesInfoInteger( a_symbol, PERIOD_M1,SERIES_SERVER_FIRSTDATE) を呼び出します。
つまり、「期間に関係なく、サーバー上のシンボルによる履歴の最初の日付」と読み取ります。
このリクエスト自体は、実際には履歴リクエストとはみなされない、つまりキャッシュが構築されることはない。
は、シンボルデータのアンロードを妨げない。SERIES_FIRSTDATEを要求するか、時系列のバーの数を要求するかは意味があることです。),
シンボルデータのアンロードを防ぐために、インジケーターに新しい関数を追加しました。
BR-8.15とBR-9.15のキャラクターでは、OnBookEvent()関数がかなりの頻度でトリガーされます。
が、結果は同じです。
で、何が問題なんだ?
なぜバーズが無理なのか?
BR-8.15とBR-9.15のキャラクターでOnBookEvent()関数がかなりの頻度でトリガーされます。
が、結果は同じです。
で、何が問題なんだ?
なぜバーズが無理なのか?
よくあること」という頻度では、自信が持てない。デバッグ用にGetBars()関数からのログ出力を追加した方が良い。
もし、それを理解したいのであれば、servicedkでリクエストを開いて ください。本格的なコード例を添付していただければ、問題の再現を試みます。
よくあること」という頻度では、自信が持てない。デバッグ用にGetBars()からのログ出力を追加した方が良い。
もし、解決したいという気持ちがあるのなら、サービスデスクでリクエストを開いてみて ください。本格的なコード例を添付して、問題を再現してみましょう。
オッケーです。リクエスト:エラー、MetaTrader 5 クライアント、オープン、開始:2015.07.24 18:28、#1267768
P/S「かなり頻繁に」は、流動性の高い2つの商品で1分間に10~100回のOnBookEvent()トリガーです。
万歳!
問題を再現した。実際、定期的なクエリを行っても、シンボルデータがメモリからアンロードされることがあった。エラーは修正されます。
ありがとうございました。
Michael さんは、他のシンボルからシリーズを取得する際のこの問題を克服することができましたか?私のインジケーターは他のシンボルと常に同期がとれなくなり、戦うのにうんざりしています。
今、デモサーバーでは、2015年6月22日のBuild 1159を配布しています。そして、その中で多通貨の指標も 恐ろしく機能する。何度か期間を切り替えたり、インジケーターを再起動したりしないと、正しく表示されません。そして、しばらくすると再びシリーズデータを取得しなくなる。いつもログに書き込んでいます。
Данные символа "Si-12.15" не синхронизированы с торговым сервером.
開発者の 皆様へ。
データが同期されて いるかどうかをチェックするのではなく、直接同期を行い、このデータをメモリからアンロードしないような関数を作ることはできないのでしょうか?
アルゴリズムの最適化という意味でも、省資源は良いことだと思います。しかし、なぜメモリからデータをオフロードすることにそこまでこだわらなければならないのでしょうか?
こんな面倒なシリーズ同期をするくらいなら、PCのメモリを1〜2GB追加で買った方がマシだ。
OnInit()で一度 呼ばれ、必要なシンボルのデータをロードし、インジケータが動作している限りアンロードされないような関数を作ってください。
最初のデート、バーの数、サーバーのことなど、ユーザーが考えるのではなく、端末がデータを用意し、その更新を監視する必要があります。
Michael さんは、他のシンボルからシリーズを取得する際のこの問題を克服することができましたか?私のインジケーターは他のシンボルと常に同期がとれなくなり、戦うのにうんざりしています。
今、デモサーバーでは、2015年6月22日のBild 1159を発行しています。そしてその中で、多通貨のインジケーターも 恐ろしく機能する。何度か期間を切り替えたり、インジケーターを再起動したりしないと、正しく表示されません。そして、しばらくすると再びシリーズデータを取得しなくなる。いつもログに書き込んでいます。
開発者の 皆様へ。
データが同期されて いるかどうかをチェックするのではなく、直接同期を行い、このデータをメモリからアンロードしないような関数を作ることはできないのでしょうか?
アルゴリズムの最適化という意味でも、省資源は良いことだと思います。しかし、なぜメモリからデータをオフロードすることにそこまでこだわらなければならないのでしょうか?
こんな面倒なシリーズ同期をするくらいなら、PCのメモリを1〜2GB追加で買った方がマシだ。
OnInit()で一度 呼ばれ、必要なシンボルのデータをロードし、インジケータが動作するまで再度アンロードされないような関数を作成します。
最初のデート、バーの数、サーバーのことなど、ユーザーが考えるのではなく、端末がデータを用意し、その更新を監視する必要があります。
こんにちは。
開発者からは、新しいビルドで修正するとの回答がありました。
発売時期は未定です。
フォルツァ関数OrderCheck()とOrderCalcMargin()が、取引に必要なGOを誤って決定し、結果としてFALSEを返してしまうことがある、という問題が発生しました。
RTS-12.15(SYMBOL_MARGIN_INITIAL)の必要GOが12,500 なので、この機能には143,105 ルーブルも必要です
同時に、すべてを手動で完璧に開くことができます。
どうやって電話するのですか?
この方法で試してみてください。
これが私の結果です。