void analyzeFilledOrder(ulong orderTicket,double volume)
{
bool isFindOrder=false;
string fullComment;
ENUM_ORDER_TYPE orderType;
if(getIsOrderOfExpert(orderTicket,true)) //Если ордер из сделки уже в истории
{
fullComment=HistoryOrderGetString(orderTicket,ORDER_COMMENT);
orderType=ENUM_ORDER_TYPE(HistoryOrderGetInteger(orderTicket,ORDER_TYPE));
isFindOrder=true; //локальная переменная, если нашли в истории
}
if(!isFindOrder && getIsOrderOfExpert(orderTicket,false)) //Если не нашли ордер в истории и ордер есть не в истории
{
fullComment=OrderGetString(ORDER_COMMENT);
orderType=ENUM_ORDER_TYPE(OrderGetInteger(ORDER_TYPE));
isFindOrder=true; //локальная переменная, если нашли не в истории
}
if(isFindOrder) //если хоть где-то нашли, то выставляем отложенные стоп ордера
{
//выставляем стоп ордера
この動画の01:35と03:35からご覧ください。
なぜ、あなたの手作りのものが必要なのですか？あなたには驚かされます。このようなプログラミングの知識では、OnTradeTransaction ハンドラを理解することはできません。
なぜ、あなたの手作りのものが必要なのですか？あなたには驚かされます。このようなプログラミングの知識では、OnTradeTransaction ハンドラを理解することはできません。
その作業を想像することもできない人に、話をするのは難しい。
では、ポジションはないのか、それとも逆コンマになっているのか。
ネッティングの観点からは、ポジションがない（すなわち、トータルポジション=0.0）のは、ごく普通の状況です。
また、2つのEAから見て、それぞれがオープンポジションを持って います。
1つのシンボルに複数のExpert Advisorが存在する場合があります。さらに、トレードによっては手探りで行うこともあります。
ネッティングの観点からは、ポジションがない（すなわち、トータルポジション=0.0）のは、ごく普通の状況です。
そして、2人のアドバイザーの立場から見ると、それぞれがオープンポジション を持っていることになります。
1つのシンボルに複数のExpert Advisorが存在する場合があります。さらに、トレードは手作業で行う場合もあります。
奥さんはナイトテーブルの中のお金を持って、テレビを買った。夫はテレビを持ち出し、それを売ってお金をナイトスタンドに入れました。ネッティングの用語では、テレビはありません。あなたの理屈だと、テレビもナイトテーブルのお金も奥さんが持っていることになりますね。そこで、テレビをもう1台買うか、テレビで得たお金を全部飲み代に使うかを決めるのです。
それとも、それぞれにテレビがあるのでしょうか？何しろ、それぞれが手にしているのだから。誇張すること。
一方のアドバイザーがポジションを開いて、もう一方のアドバイザーがクローズしたら、もうダメだ...。忘れてください...ポジションはありません。
奥さんは、ナイトテーブルの中のお金を持って、テレビを買いました。夫はテレビを持ち出し、それを売ってお金をナイトスタンドに入れました。ネッティングの用語では、テレビはありません。あなたの理屈だと、テレビもナイトテーブルのお金も奥さんが持っていることになりますね。そこで、テレビをもう1台買うか、テレビで得たお金を全部飲み代に使うかを決めるのです。
それとも、それぞれがテレビを持っていたのでしょうか？何しろ、全員が手にしたことがあるのですから。大げさですね。
一方のアドバイザーがポジションを開いて、もう一方のアドバイザーがクローズしたら、もうダメだ...。忘れてください...ポジションはありません。
ポジションがないんです。
しかし、そのロジックの一環として、それぞれのEAが異なるポジションをとっているのです。例えば、一人の「長期派」が損切りを我慢し、もう一人の「スキャルパー」が逆張りを同時にする。
ポジションはありません。
しかし、そのロジックの範囲内で、それぞれのEAが独自の立場を貫いているのです。例えば、「長期派」は損切りを待つ、「スキャルパー派」は逆張りを狙う。
どうやら、2つのヘッジ戦略の論理をネッティングに当てはめようとしているようですね。より論理的な順序としては、次のようになります。
カウンタートレンドに乗ったスキャルパーがポジションを閉じ、想像上のポジションの予想TP価格で指値注文を設定します。そして、このリミットスイッチが機能すれば、ポジションは完全に元に戻る BUT!!! 別のチケットで。そのため、そのクローズしたポジション の継続とみなすことは絶対に正しくありませんし、長期EAもそのポジションと判断することはできません。
もうひとつは、そのスキャルパーが小さいボリュームで動作するかどうかです。そうすると、初値が変わるにもかかわらず、チケットは同じままです。一般的に、ヘッジのために戦略を単純にネッティングに移そうとしないでください、何も良いことはありません。例えはうまくいくが、行動は違うはずだ。ネッティングの仕様を考慮する必要がある。
どうやら、2つのヘッジ戦略の論理をネッティングに当てはめようとしているようですね。より論理的な順序としては、次のようになります。
カウンタートレンドのスキャルパーは、ポジションを決済し、想定されるTP価格で指値注文を設定し、架空のポジションを持つことになります。そして、このリミットスイッチが機能すれば、ポジションは完全に元に戻る BUT!!! 別のチケットで。そのため、そのクローズしたポジションの 継続とみなすことは絶対に正しくありませんし、長期EAもそのポジションと判断することはできません。
スキャルパーがより小さな値で動作する場合は、全く別の問題です。そうすると、初値が変わったにもかかわらず、チケットは同じままです。一般に、ネッティング戦略を単純にヘッジに移そうとすると、何も良いことはありません。例えはうまくいくが、行動は違うはずだ。ネッティングの仕様を考慮する必要がある。
これはスキャルパーとロングライザーの例であり、シンボルには多くのEAが存在し、ロットも異なる場合があります。
"スキャルパーはカウンタートレンドでポジションを閉じ、彼の想像上のポジションの予想TPの価格にリミットストップを置く。- しかし、スキャルパーは「架空のポジション」を持っていることを自ら想定している。
そして、トータルポジションがチケットを変えたという事実 - だから、長期アドバイザーはそれを必要としない、彼はすでにトータルポジションとは関係のない自分のポジションを持っていることを知っている。
その結果、すべてのEAは、このシンボルで他の誰が作業しているかに関係なく、何も知らず、何も知りたくもなく、動作します。
そうそう、私はMT5、FORTS、ネッティングをすぐに始めたので、ヘッジ用のストラテジーを移し替えようとしているわけではありません。ただ、複数のロボットがシンボルで取引でき、なおかつそれを邪魔することなく手を動かすことができるようにしたかったのです。
JRandomTrader:
しかし、自分にとって、浪費家は「架空のポジション」を持っていると考えている。
それこそ、ネトゲとは別のロジックを構築しないといけない。イマジナリーポジションは ないはずです。他に理解してもらえるような言葉が見つからなかったから、そう言っただけなんだ。もしフィルがあれば、ポジションの総量とオープンポジションの 新価格が考慮され、もし部分的なクローズがあれば同じで価格と量が考慮されます。
それこそ、ネトゲとは別のロジックを構築しなければならない。イマジナリーポジションがあっては ならない。他に理解してもらえる言葉が見つからなかったから、そう言っただけなんだ。フィルがあった場合は、ポジションの総量と新しい始 値が考慮され、部分的にクローズがあった場合は、同様に価格と量の合計が考慮されます。
そして、ロボット同士の相互作用を確立し、今日は同じでも明日は違うかもしれない「隣人」の行動を考慮する必要があります。そして、これがどのような利益をもたらすかは不明です。
ロボットのアルゴリズムの観点からも虚位が必要で、開いたのなら閉じるべき。
そして、ロボット同士の相互作用を作り出し、今日は一人、明日は別の人という「隣人」を考慮に入れなければならないのです。そして、これがどのような利益をもたらすかは不明です。
ロボットのアルゴリズムからすると、開けたら閉めるという虚位の位置が必要です。
物事を単純化すると、そうですね。私もそう思います。
それなら、「運輸支局長」は問題点と行動を明確にし切れていない。
トレーディング、自動売買システム、ストラテジーテストに関するフォーラム
OnTradeTransaction処理
イリヤ・チャイルド さん 2019.02.07 20:08
こんばんは。
みんな、これを解決するのを手伝ってくれ。この問題はおそらく新しいものではないのですが、（実際にもフォーラムでも）明確な解決策は見つかっていません。
ターミナルで2種類のロボットを2種類の計測器で動かしています。魔法はどこでも違うんです。ロボットは保留中の制限を置き、OnTradeTransaction 手続きで取引を検出し、この取引を使用して保留中のストップオーダーを置くことができます。
以下は、貿易取引に関するコードです。
これは、取引がロボットに属するかどうかをチェックする関数のコードです。
これは、ストップオーダーを保留する手順のコードです。
以下は、履歴の中の注文と履歴の外の注文を検索する関数のコードです。
端末に受信したトランザクションの情報を順番にログファイルに出力していくんだ。さて、デモ口座での取引で直面した問題があります。
トランザクションは、TRADE_TRANSACTION_ORDER_DELETE、TRADE_TRANSACTION_DEAL_ADD、TRADE_TRANSACTION_HISTORY_ADDの順で行われることがあるようです。この場合、ストップ注文は取引が成立した後に発注されないことが多い。これは、注文がすでに削除されているにもかかわらず、まだ履歴に追加されていないために起こるのでしょう。履歴にも端末にも、その取引からの注文が見つからないということです。疑わしいが，ロボットが全次元で注文を検索しても見つからなかった（isFindOrder=false）ため，逆指値注文が出されていないのが実情である。取引の順番は正しいが、注文がどこにもない場合がある。 いずれの場合も、ロボットは取引を正しく検出するが、注文を出すまでには至らない。ただし、正しく動作し、注文が出る場合もある。
いろいろな方法を試したが、うまくいかない。今、考えているのは、注文を保留する手順の最初に1秒のインターバルを設けることです。他にどこを掘ればいいのかわからない。
あなたの経験やアイデアをお聞かせください。