Предпосылки очень просты -- таймер обычно используется для синхронизации (ждем расчета данных) или обсервинга (зацикленный таймером эксперт, имхо, будет гораздо более адекватным).
2011.05.12 16:42:57 Traes '726238' : キャンセルオーダー #4388299 buy stop 0.02 EURUSD at 1.41700 done- order successfully deleted. 2011.05.12 16:42:57 トレード '726238' : キャンセルオーダー #4388299 buy stop 0.02 EURUSD at 1.41700- Another request is being sent. 2011.05.12 16:42:58 Trades '726238' : failed cancel order #4388299 buy 0.00 at 0.00000 [Invalid request]- It was buy for some reason.
У вас в mql4 стоит проскальзывание 50, а в mql5 10. Попробуйте поставить одинаковое проскальзывание возможно ситуация выровняется тк много приказов с таким слипажем может просто попадать на реквот.
1)"stacks in common queue" - ドキュメントの間違いです。実は、たくさんの行列があるんです。現在、すべてのmql5プログラム、すべてのチャートが独自のキューを持っています。キューのサイズはそれぞれ異なり、一般に小さくはない、キューのオーバーフローは正しく書かれたプログラムではありえない。各キューの正確なサイズやその数、その他内部実装の詳細な説明については文書化しない予定です。理由は至極当然で、内部実装が変わる可能性があるからです。
ハンドブックより
Все возникающие события клиентский терминал складывает в общую очередь.
...イベントキューはサイズに制限が あります。
それで、誰か助けてくれるのか、くれないのか？25ページには、2人の参議院議員...
叱ることは叱る。さあ、理解を深めてください。あなたは、私が問題を分析するのに十分なデータを与えていないと非難しましたね。これ以上は必要ない。好きなものをチェックすることができます。
みんな私のロボットを試しているんだなあ...。待ちます。おそらく、バグを見つけるためにプログラマーをお金で雇う必要があるのでしょう。
ところで、このスレッドのトピックが何という名前か覚えている人はいるだろうか......？
ハンドブックより
イベントキューについては議論がありましたが、正確なサイズがわかりませんでした。イベントキューの深さは？64?256って......イベント？
また、イベントキューが溜まって詰まったらどうなるのか、新しいイベントは無視されるのか、すでにキューにあるイベントはリセットされるのか、そしてもちろん、いつ（キューのどのイベントで）そうなるのか、お聞きしたいのです。
既出
https://www.mql5.com/ru/forum/1621/43941#comment_43941
既出
https://www.mql5.com/ru/forum/1621/43941#comment_43941
答えはあるのに、それがぼやけている。私の疑問は、ヒントにもなっていない。
キューの長さの正確な表示も、どのイベントがスキップされるか（「イベントの一部がスキップされる」とはどういう意味ですか？ 新しいイベントと既にキューにあるイベントのどちらが重要か？新しいイベントがキューにあるイベントより重要かもしれないし、その逆もあるので、ここでは論理は無力です。
だから、この点をはっきりさせた方がいいんです。
それで、誰か助けてくれるのか、くれないのか？25ページには、2人の参議院議員...
叱ることは叱る。さあ、理解を深めてください。あなたは、私が問題を分析するのに十分なデータを与えていないと非難しましたね。これ以上は必要ない。好きなものをチェックすることができます。
みんな私のロボットを試しているんだなぁ...。待ちます。おそらく、バグを見つけるためにプログラマーをお金で雇う必要があるのでしょう。
ところで、このスレッドのトピックが何という名前か覚えている人はいるだろうか......？
mql4で50、mql5で10のスリッページがありますね。同じスリッページを設定してみると、そのようなスリッページの注文が多くてもリクオートになってしまうだけなので、もしかしたら状況が均等化するかもしれません。
さらに、両方のバリエーションでスリッページをスプレッドサイズに 設定するのがよいでしょう。
繰り返し質問させていただきます。
特定のマジックを持つオーダーを正しく削除するにはどうしたらいいですか？
...例えばこんな風に、注文のリストを上から下へと見ていく必要があるのです。
おっしゃるとおりにしてみましたが、問題はそのままです。保留中の注文が まず削除され、次に同じ注文を削除するための別のリクエストが送信されます。以下は、ログ行の一例です。
2011.05.12 16:42:57 Traes '726238' : キャンセルオーダー #4388299 buy stop 0.02 EURUSD at 1.41700 done- order successfully deleted.
2011.05.12 16:42:57 トレード '726238' : キャンセルオーダー #4388299 buy stop 0.02 EURUSD at 1.41700- Another request is being sent.
2011.05.12 16:42:58 Trades '726238' : failed cancel order #4388299 buy 0.00 at 0.00000 [Invalid request]- It was buy for some reason.
この現象は毎回起こるわけではなく、時々起こるもので、Expert Advisorの動作に影響はありません。私はただ、すべてを正しくして、空のリクエストでトレードサーバーに負荷をかけないようにしたいし、問題を理解したいだけです。
お返事をいただき、ありがとうございました。
-----------------
私なりの意見を言ってみる。あるマジックナンバーのオーダーを削除しても、他のオーダーを削除しても、問題は変わりません。また、オーダーを縦方向や横方向にスクロールすることもできます。注文を記憶しておき、チケットで削除すると、たまにエラーが出ます。
想像するに、ログにあるメッセージとサーバーのretcodeレスポンスからわかるように、サーバーは確かに注文を削除したのでしょう。しかし、端末はまだそのことを知りません。つまり、注文はまだその端末で機能しており（あるいは知っているが、EAに古い情報を与えており、その時はチェックに失敗していたでしょう）、次のティックでそれを削除するために別のリクエストを送り、サーバーからエラーを得ます。
逆指値注文を単純な買い注文にしてしまったのは、サーバーのミスと思われる：リクエストエラーの場合、これらの注文を区別していないのだ。これは、開発者の方にも覚えておいていただきたいことです。
繰り返しの要求を避けるには？方法は2つしかないと思うんです。
1.削除に成功したら、最後の履歴を解析し、削除したオーダーが表示されるのを待ち、次に進みます。
2. 削除が完了してから、例えば2秒間の遅延を導入するだけです。1つでは足りないかもしれません。
また、この状況は、保留中の注文だけでなく、成行注文や、ポジションを変更した場合にも発生することを付記しておきます。この現象は、デモ口座で長時間取引した場合にのみ発生することがありますが、テスターでは、もちろん表示されません。また、ポジションを変更した後、変更前のマージンレベルが逆になることがあります。おそらく他の口座パラメータも同様だと思いますが、確認していません。
У вас в mql4 стоит проскальзывание 50, а в mql5 10. Попробуйте поставить одинаковое проскальзывание возможно ситуация выровняется тк много приказов с таким слипажем может просто попадать на реквот.
そしてさらに良いのは、両方のバリエーションで、スプレッドの大き さにスリッページを設定することです。
試してみますが、状況がマニホールド改善されるとは思えません。
プログラミングに問題があるのか、それとも何も問題がないのか？
答えはあるのに、それがぼやけている。私の疑問は、ヒントにもなっていない。
キューの長さの正確な表示も、どのイベントがスキップされるか（「イベントの一部がスキップされる」とはどういう意味ですか？ 新しいイベントか、すでにキューに入っているイベントか？ 新しいイベントの方がキューに入っているイベントより重要かもしれないし、その逆かもしれないので、ここでは論理は無力です。
だから、この点をはっきりさせた方がいいんです。
1)"stacks in common queue" - ドキュメントの間違いです。実は、たくさんの行列があるんです。現在、すべてのmql5プログラム、すべてのチャートが独自のキューを持っています。キューのサイズはそれぞれ異なり、一般に小さくはない、キューのオーバーフローは正しく書かれたプログラムではありえない。各キューの正確なサイズやその数、その他内部実装の詳細な説明については文書化しない予定です。理由は至極当然で、内部実装が変わる可能性があるからです。
2) このキューに十分なスペースがない新しいイベントは、スキップされます。
新しいティックとチャートの変化というイベントは、mql5プログラムの受信イベント・キューに1つだけ存在することができることを思い出してください。チャート上のグラフィカルオブジェクトの作成および削除のイベント生成の有効/無効を設定可能。
下の方にある緑のバーの意味を教えてください。MT4ではロット数量を意味し、ロット変更時に描画された。しかし、ここでは何のためにあるのか？それとも、私のロット数が変わるのでしょうか？どうやら私は変えていないようです。