エラー、バグ、質問 - ページ 2219

 
fxsaber:


ForexTimeFXTM-Demo01での 結果です。


スクリプトは、現在の注文でも履歴でもない「幻の注文」を検出するまで、ポジションを開いたり閉じたりする。バグと考えるべきか、それともプラットフォームの機能と考えるべきか。


このようなニュアンスで、いくつかのポジションが開くことがあるように脚本が書かれているのです。しかし、「幻の注文」を受けることを防ぐことはできません。

オタク的というか、こういう表現が好きなんです。

(ENUM_ORDER_TYPE)(1 - PositionGetInteger(POSITION_TYPE))

あなたは、あるenumのすべての数値とその順番を暗記しているかもしれませんが、他の人はこれらの根性を知らないかもしれません。 enumをこのように扱うべきではありません。 簡潔さは確かに才能の妹ですが、それは品質を損なわない場合に限ります。

また、今回の件で言えば、オープンするポジションを確認するのは、result.orderではなく、order.dealです。 それぞれ、オーダーではなく、ポジションの中にあるはずです。 そうでしょうか?

 
Alexey Navoykov:

短さはもちろん才能の妹分ですが、質を損なってはいけません。

MQLではよくある操作のようです。

また、今回の件で言えば、result.orderではなく、order.dealでオープンするポジションを確認すべきです。 従って、オーダーではなく、ポジションの中から探すべきですね。 そうでしょうか?

OrderSendの 直後に送信される最初のオーダーは、どこにも見つからないかもしれません。ポジションは、オーダーよりずっと後です。


ZZY コードには、あえて取引アルゴリズムの中で最も分かりやすい言語であるMQL4でコメントを残しました。

 
fxsaber:

OrderSend直後に送信されるオリジナルのオーダーは、どこにもない可能性があります。ポジションは、オーダーよりずっと後です。

そんなことより、実はドキュメントによると、OrderSendはチケットを受け取る必要がないらしい。

成行注文(MqlTradeRequest.action=TRADE_ACTION_DEAL)を送信する際、OrderSend()関数の成功結果は、注文が実行された(対応する取引が実行された)ことを意味しません。 この場合、trueは、さらなる実行のために取引システム内に注文が正常に配置されたことだけ意味しています。取引サーバはOrderSend()コール生成時にこれらのデータが既知で ある場合、返された結果構造 体の結果フィールドの値を埋めることができる一般的には、OrderSend()呼び出し応答が送信された後に、注文に対応する案件のイベントが発生することがある。し たがって、どのような種類の取引要求であっても、OrderSend()の結果を受け取る際には、まず返された結果構造 体の中にある取引サーバのリターンコードretcode と外部取引システム応答コードretcode_external(必要な場合)を確認する必要が あります。

ですから、いずれにしてもOnTradeTransactionなしには成り立ちません。

つまり、MQL5では同期トレード操作が保証されていないことが判明した。

 
Alexey Navoykov:

ドキュメントによると、OrderSendはチケットを受け取る義務はないようなので、特に問題ではありません。

そのため、OnTradeTransactionはどのような場合でもチェックする必要があります。

いずれにせよ確認する必要はありません。あくまでオプションです。

同期OrderSend後のResult.orderが0でないことは、常に取引サーバから注文が登録された応答を受信したことを意味する。このチケットはまさにサーバーから来たものです。また、OrderSend が成功した場合、このチケットは常に受信されます。

しかし、残念なことに、OrderSendではなく、注文を取引に受け入れる瞬間に起こってしまうようです。このような場合のために、ORDER_STATE_REQUEST_ADDが あるが。とにかく、MQからの答えを待っている。私見ですが、取引サーバーに注文があるのに、端末でsynchronous OrderSendした後、何も言われないのはバグだと思います。

 
fxsaber:

とにかくMQからの返事を待つことだ。私見ですが、取引サーバーに注文があるにもかかわらず、端末でsynchronous OrderSendした後、注文の形跡がないのはバグだと思います。

もっと言えば、OrderSendの完全な同期性を端末とサーバーの両方で保証するよう開発者に求めるべきです。 そうでなければ、実行の同期性が保証されないなら、なぜこの関数が必要なのでしょうか? この目的のために、既にOrderSendAsyncが あります。

 
Dmitriy:

こんにちは。本日、バージョン1860にアップデートし、Expert Advisorを最適化しているときに、この問題に遭遇しました。

パス間の遅延は1分!?何が問題なのか、アドバイスをお願いします。

p.s. アップデート前は、すべてが規則正しく動いていました。

ひょっとしてBars機能を使っているのでしょうか?
その場合は、こちらを ご覧ください。

 

ちょっと質問です。

共通のファイルを作ることに意味があるのかも?ただ、mq4やmq5の名前が常に変更されているのが気になります。プロジェクトとの 関連で、mqのような共通の拡張子を作ったらどうかと考えていたのですが、どうでしょうか?

しかも、拡張機能で編集することなく、端末から端末へコードをコピーするだけ...。

 
Vladimir Pastushak:

ちょっと質問です。

共通のファイルを作ることに意味があるのかも?ただ、mq4やmq5の名前が常に変更されているのが気になります。 プロジェクトとの関連で、mqのような共通の拡張子を作ったらどうかと考えていたのですが、どうでしょうか?

しかも、拡張機能で編集することなく、端末から端末へコードをコピーするだけ...。

また、これらのコードをmqhファイルに書き、(#include) を使って接続することを誰が禁じているのでしょうか。それは、かなり以前からやっていたことです。

 
Konstantin Nikitin:

そして、これらのコードをmqhファイルに書き、(#include) で接続することを誰が禁じているのでしょうか。これは、かなり以前からやっていたことです。

プラグインすると、拡張子が変わる・・・ご近所さん。

 
Alexey Navoykov:

もっと言うと、OrderSendが端末とサーバーの両方で完全に同期していることを保証するように開発者に求めるべきです。 そうでなければ、同期実行が 保証されないなら、なぜこの関数が必要なのでしょうか? この目的のために既にOrderSendAsyncがあるのです。

整理しますとプラットフォームの取引システムと端末本体へのORDER投稿の同期化。