C-4、ご意見ありがとうございます。
C-4:
私の経験から言うと、TradeTransactionを使う本当の必要性は、非同期モードでプログラミングするときに生じます。この記事にはこのモードについて一言も書かれていないのが残念です.
TradeTransactionハンドラーを使う理由となるニーズや要件は様々です。これは興味深いトピックなので、経験豊富な同僚がこの問題についてコメントしてくれることを期待しています。
s.s. 私も「MQLレシピ」だと思っていました。- はアナトリーの 記事のブランド名だと思っていました。今はそうではないことがわかりました(
そうです、アナトリーが この連載の発案者であることは認めます。私はそれが気に入ったので、控えめにそのサイクルに加わりました :-)))
アナトリーが気にしなければいいのだが...。
この記事では、部分的な注文執行(ORDER_STATE_PARTIAL)の問題を取り上げる時間がまだありませんでした。TradeTransactionハンドラーは何回呼び出されるのでしょうか?
わかりません。論理的には、ハンドラーは完全な約定と同じ回数トリガーされるはずです。なぜなら、注文の執行は個別のイベントではなく、MT は注文が部分的に執行されるか完全に執行されるかを知らないからです。
s.s. 残念ながら、イベントの配信は保証されておらず、イベント自体もリアルタイムでしか機能しないため、その用途は限られている。しかし、非同期システムやトレード・コピー機など、状態追跡をベースとするシステムには非常に有用である。イベントのおかげで、ループやOnTimerイベント待ちによる追加ブレーキなしにアルゴリズムを構築することができる。
この記事をありがとう。とても役に立つ。
こんにちは、
私の状況は非常に単純です:ペンディングオーダー(Sell_Stop)を発注し、a)ペンディングオーダーが満たされ、b)オープンポジションがストップロスまたはプロフィットターゲットによってクローズされた場合に反応できるようにしたいのです。
私の理解は正しいでしょうか?
- OnTradeTransaction()のパラメータ "request "が "magic "フィールドを所有しているにもかかわらず、保留中の注文が満たされたとき、私はポジションリストからマジックナンバーをリクエストすることによってのみ、 マジックナンバーを取得することができます:
if(!PositionSelectByTicket(trans.position)) {Print(__LINE__," PositionSelectByTicket FAILED ",err());} else { OpnPos[sz].mag = PositionGetInteger(POSITION_MAGIC); }
- 売りポジションがオープンされたのかクローズされたのかを知ることができないように、様々なトランザクショ ン・タイプがある:
void OnTradeTransaction(const MqlTradeTransaction& trans, const MqlTradeRequest& request, const MqlTradeResult& result) { //--- //--- static int counter=0; // OnTradeTransaction() 呼び出しのカウンタ static uint lasttime=0; // OnTradeTransaction() が最後にコールされた時刻。 //--- uint time=GetTickCount(); //--- 最後のトランザクションが1秒以上前に実行された場合、 if(time-lasttime>1000) { counter=0; // その場合、これは新しい取引操作であり、カウンタはリセットされる。 if(IS_DEBUG_MODE) Print(__LINE__," "," New trade operation dTime",time-lasttime); } Print(__LINE__," ",counter," ",DoubleToString((double(lasttime=time)/1000.0,2) ," Tr.Type: ",EnumToString(trans.type)," DL.Type: ",EnumToString(trans.deal_type) ," RQ.Type: ",EnumToString(request.type)," RQ.Fill: ",EnumToString(request.type_filling) );
このプリントは、01:00:40にポジションをオープンし、10:04:40にポジションをクローズした場合に生成されます:
01:00:40 322 0 81952.76 Tr.Type: TRADE_TRANSACTION_DEAL_ADD DL.Type: DEAL_TYPE_SELL RQ.Type: ORDER_TYPE_BUY RQ.Fill: ORDER_FILLING_FOK // open sell position 10:04:40 322 0 81970.73 Tr.Type: TRADE_TRANSACTION_DEAL_ADD DL.Type: DEAL_TYPE_BUY RQ.Type: ORDER_TYPE_BUY RQ.Fill: ORDER_FILLING_FOK // close sell position 01:00:40 322 0 81955.30 Tr.Type: TRADE_TRANSACTION_ORDER_DELETE DL.Type: DEAL_TYPE_BUY RQ.Type: ORDER_TYPE_BUY RQ.Fill: ORDER_FILLING_FOK // open sell position 10:04:40 322 0 81980.91 Tr.Type: TRADE_TRANSACTION_ORDER_DELETE DL.Type: DEAL_TYPE_BUY RQ.Type: ORDER_TYPE_BUY RQ.Fill: ORDER_FILLING_FOK // close sell position 01:00:40 322 0 81965.14 Tr.Type: TRADE_TRANSACTION_HISTORY_ADD DL.Type: DEAL_TYPE_BUY RQ.Type: ORDER_TYPE_BUY RQ.Fill: ORDER_FILLING_FOK // open sell position 10:04:40 322 0 81982.69 Tr.Type: TRADE_TRANSACTION_HISTORY_ADD DL.Type: DEAL_TYPE_BUY RQ.Type: ORDER_TYPE_BUY DL.Type: ORDER_FILLING_FOK // close sell position 01:00:59 322 0 81968.50 Tr.Type: TRADE_TRANSACTION_REQUEST DL.Type: DEAL_TYPE_BUY RQ.Type: ORDER_TYPE_SELL RQ.Fill: ORDER_FILLING_FOK // open sell position
コールはほとんど同じに見えますが、どうしてですか?1:00に売りがオープンされた - なぜ12個の.TYPE_BUYがあり、2個のTYPE_SELLしかないのか?
売りのストップがトリガーされ、売り(ポジション)になった場合のrequest.type = ORDER_TYPE_BUYの理由と意味は?どこから_BUYですか?
- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索
新しい記事 MQL5 クックブック:トレードトランザクションイベントの処理 はパブリッシュされました:
本稿では MQL5 の手段を利用してトレードイベントを管理する方法の一つを提案したいと思います。すでにこのテーマについて述べた記事が数点あることを述べておく必要があると思います。"Processing of trade events in Expert Advisor using the OnTrade() function" はそのうちの一つです。私は他の著者の言うことを繰り返す気はありません。また私は別のハンドラ-OnTradeTransaction()を利用するつもりです。
読者のみなさんには以下のポイントに関心を示していただきたいと思います。現在の MQL5 言語は正式にクライアントターミナルの 14 のイベントハンドラを対象とします。また、プログラマーはEventChartCustom() を用いてカスタムイベントを作成し、OnChartEvent() でそれらを処理することができます。ただし「イベント駆動型プログラミング」(EDP)という言葉はドキュメンテーションでは全く使用されていません。 MQL5 のプログラムがどれも EDP 原則にのっとって作成されている事実を踏まえると、それはおかしなことです。たとえば、ユーザーはどんな Expert Advisor でもテンプレートにある「エキスパート用イベントハンドラ」のステップで選択をすることになります。
イベント駆動型プログラミングのメカニズムがいずれにせよ MQL5 で使用されているのは明らかです。この言語には2部で構成されるプログラムブロックがあります。:イベントの選択と処理です。その上、クライアントターミ ナルのイベントについて語るなら、プログラマーは後者のみ制御します。すなわちイベントハンドラです。公正を期すために申し上げると、イベントによっては 例外もあります。タイマーとカスタムイベントはその例外に入ります。こういったイベントの制御は完全にプログラマーに委ねられています。
作者: Dennis Kirichenko