voidOnTradeTransaction( constMqlTradeTransaction &trans, constMqlTradeRequest &request, constMqlTradeResult &result )
{
// Print( "Ticket = ", string( trans.order ), " --> ", EnumToString( trans.type ), " --> ", EnumToString(trans.order_state) );switch( trans.type )
{
TRADE_TRANSACTION_ORDER_DELETE: switch( trans.order_state )
{
Удаление ордера из списка открытых.
Ордер может быть удален из открытых в результате выставления
соответствующего запроса либо в результате исполнения (заливки) и переноса в историю.
}
break;
TRADE_TRANSACTION_ORDER_ADD: switch( trans.order_state )
{
Добавление нового открытого ордера.
}
break;
TRADE_TRANSACTION_DEAL_ADD: switch( trans.order_state )
{
Добавление сделки в историю. Осуществляется в результате исполнения ордера или проведения операций с балансом счета.
}
break;
caseTRADE_TRANSACTION_HISTORY_ADD: switch( trans.order_state )
{
Добавление ордера в историю в результате исполнения или отмены.
}
break;
caseTRADE_TRANSACTION_ORDER_DELETE: switch( trans.order_state )
{
Удаление ордера из списка открытых.
Ордер может быть удален из открытых в результате выставления
соответствующего запроса либо в результате исполнения (заливки) и переноса в историю.
}
break;
caseTRADE_TRANSACTION_ORDER_UPDATE: switch( trans.order_state )
{
Изменение открытого ордера.
К данным изменениям относятся не только явные изменения
со стороны клиентского терминала или торгового сервера,
но также и изменение его состояния при выставлении
(например, переход из состояния ORDER_STATE_STARTED в ORDER_STATE_PLACED или
из ORDER_STATE_PLACED в ORDER_STATE_PARTIAL и т.д.).
}
break;
caseTRADE_TRANSACTION_DEAL_UPDATE: switch( trans.order_state )
{
Изменение сделки в истории. Возможны ситуации,
когда ранее исполненная сделка изменяется на сервере.
Например, сделка была изменена во внешней торговой системе (бирже),
куда она была выведена брокером.
}
break;
caseTRADE_TRANSACTION_DEAL_DELETE: switch( trans.order_state )
{
Удаление сделки из истории.
Возможны ситуации, когда ранее исполненная сделка удаляется на сервере.
Например, сделка была удалена во внешней торговой системе (бирже), куда она была выведена брокером.
}
break;
caseTRADE_TRANSACTION_HISTORY_UPDATE: switch( trans.order_state )
{
Изменение ордера, находящегося в истории ордеров.
Данный тип предусмотрен для расширения функциональности на стороне торгового сервера.
}
break;
caseTRADE_TRANSACTION_HISTORY_DELETE: switch( trans.order_state )
{
Удаление ордера из истории ордеров.
Данный тип предусмотрен для расширения функциональности на стороне торгового сервера.
}
break;
caseTRADE_TRANSACTION_POSITION: switch( trans.order_state )
{
Изменение позиции, не связанное с исполнением сделки.
Данный тип транзакции свидетельствует именно о том,
что позиция была изменена на стороне торгового сервера.
У позиции может быть изменен объем, цена открытия,
а также уровни Stop Loss и Take Profit.
Информация об изменениях передается в структуре MqlTradeTransaction
через обработчик OnTradeTransaction.
Изменение позиции (добавление, изменение или ликвидация) в результате совершения
сделки не влечет за собой появление транзакции TRADE_TRANSACTION_POSITION.
}
break;
caseTRADE_TRANSACTION_REQUEST: Уведомление о том, что торговый запрос обработан сервером,
и результат его обработки получен.
Для транзакций данного типа в структуре MqlTradeTransaction
необходимо анализировать только одно поле - type (тип транзакции).
Для получения дополнительной информации необходимо анализировать второй
и третий параметры функции OnTradeTransaction (request и result).
break;
}
なんてことだ!歴史の中で有効なのか?
papaklassは、おそらくOnTradeTransactionがエラーを返すという意味でしょうか。
OnTradeTransactionの 情報が有効でない可能性がある場合、履歴から取り出して有効であることを確認する必要があるのです。
onTradeTransactionの情報が必ずしも信頼できるものではない場合、情報が処理されたことを確認するために、履歴から取得する必要があるのです。
問題は、どうせ履歴から情報を取るのであれば、一体なぜOnTradeTransactionが必要なのか、ということです。- エラーチェックのためにだけ必要なのです。ブローカーが注文を拒否したので、OnTradeTransactionで拒否された理由を回答してもらい、それを分析しました。
しかし、なぜ9ページもあるのに垂涎の的なのか?
失礼のないようにお願いしますところで、もう10なんですねー。
そして、ここに書かれていることを全く読まないことも、あなたの権利の範囲内です
C-4,はもちろん処理されますが、なぜOnRefresh()が必要なのでしょうか?
多くのイベント→1つのハンドラ
各コーナーからのエラーは一山に!:)
送信されるのはエラーではなく、データです。エラーはハンドラーにあるかもしれないが、ハンドラーは1つしかないので、簡単に修正できる。
まさにその通りです。イベント分離が必要です。
送信されるのはエラーではなく、データです。エラーはハンドラーにあるかもしれないが、ハンドラーは1つしかないので、簡単に修正できる。
イベントを分ける必要はなく、ハンドラを分ける必要がある。イベントはデータを生成します。データ型 ごとにハンドラを処理する。誰がデータを受け取ったかは問題ではなく、重要なのは、データ型ごとに固有のハンドラが存在することです。ここで分離されないものは何ですか?
そして、そこには
ここで共有されていないものは?
ご指摘の内容(データタイプの処理)は、今のところMKが持っているものです。OnTradeTransaction ハンドラは、特定の MqlTradeTransaction データタイプを処理します。たしかに、このデータ型にはいろいろなもの、つまりさまざまな事象に対応するデータ型が入れられていますね。
すべてのイベントは、独自のデータと独自のハンドラを持つことを提案します。イベントの数だけ、ハンドラの数がある。イベントの区分(ポジションを開く、ポジションを閉じる、注文を出す、注文を修正する、ポジションを修正する、など)です。そして、どのイベントにどのようなデータ型を割り当てるかは、開発者が決めることである。
ハンドラ」という言葉は、あるイベントを受け取るシステム関数ではなく、このイベントを分析するExpert Advisorのモジュールを意味します。機能数を増やすために On...それぞれ独自のイベントに対応するのは意味がなく、適切な量のユーザーハンドラを作成するのが初歩的です。私の場合、こうしています。
同じEventクラスが、全く異なるタイプのデータを必要とする全く異なるハンドラに渡されるのは、奇妙に思えるかもしれません。例えば、OnMouseMove はマウスで押されたキーのマスクとその座標、OnKeyDown() は押されたキーのコード、OnOrderChange は変更されたオーダーのチケットとおそらく正確な変更を記述した enum が必要です。イベントクラスには、考えられるすべてのイベントのためのフィールドが含まれていると思うかもしれません。でも、そうではないんです。実際、イベントクラスのオブジェクトは、コンストラクタが保護領域に隠されているため、存在することすらできないのです。しかし、その子孫は数多く存在し、それぞれが異なるイベントのみを処理するようになっています。しかし、どんなイベントにも、それがどのタイプに属するかを示す識別子が存在する。この識別子を知っていれば、安心して大きなタイプから小さなタイプに変換することができます。ハンドラが渡されたときに暗黙の変換が行われる子の型である。では、実際にハンドラがどのようにイベントを見るか見てみましょう。
美しい...イベントは1つしかないように見えますが、実は何十個もある可能性があります。イベントには型以外の情報はないように見えるが、実はハンドラは自分だけが知っているメソッドを自由に参照することができる。外的」「内的」な事象はなく、ただ事象があるだけです。そして、その数は無限に広がる可能性を秘めています。イベントというのは何でもいいんです。イベントにはあらゆる種類のデータを含めることができます。この哲学に従うことで、私たちはより高いレベルのデータの抽象化に到達することができるのです。なぜ、頭の中で制限を作るのか、なぜ、分類制限の抽象度を押し付けるのか!?
内部イベントと外部イベントの本質的な違いは、実行時間である。内部イベントの実行時間は実質ゼロ、外部イベントの実行時間は数百ミリ秒から数秒。
イベントには実行 時間がありません。イベントが到着している場合は、すでに実行されています。これが非同期モードの仕組みです。だから、イベントの実行速度で内部と外部に分類するのは間違いだ。全く分類せず、具体的な実装から非常に抽象的に考えるのが正解です。