В тестовых советниках же показываются все данные последнего выставленного ордера или открытой позиции.Это означает, что библиотека знает эти данные.В ней реализован событийный функционал, и о всех установленных событиях библиотека собщает.Соответственно, вам нужно контролировать эти события и получать объект последнего ордера или позиции, а из него брать тикет (и все остальные параметры ордера или позиции).Сейчас пока нет возможности привести какой-либо пример.Но в скором времени вернусь и смогу помочь .Можете самостоятельно поглядеть откуда тестовые советники берут данные о событиях и распечатывают их в журнал.Соответственно, можете из своей программы получить доступ к той же точке и брать данные от этих событий.
Всё очень просто.MQL5を使用する場合、次のようにします。Успешность отсылки - это просо проверка на корректность параметров в торговом приказе.Исполнение приказа лежит на стороне биржи.Мы можем лишь использовать факт изменения торгового окружения, и после обнаружения его изменения уже двигаться дальше.Именнопоэтой причине я не использую данные, полученные в ответе сервера.
Покавсе последующие версии посвящены созданию индикаторов.
Скоро опять вернусь к советникам.Там и проверю сообщения пользователей о том, что некоторые торговые события (происходящие одновременно) теряются. И там же смогу тогда показать как использовать событийную модель библиотеки.
I have already mentioned the concept of a pending request in a number of previous articles. In this article, we are going to figure out what it is and why we need it, as well as start implementing pending requests. When receiving and handling a trade server error, we sometimes need to wait and repeat the request. In the simplest case, waiting...
ありがとう、これは重要で有益な作品だ...。
ありがとう、これは重要で有益な作品だ...。
どういたしまして
Artyomさん、こんにちは - 注文またはポジションを建てた後にチケット番号を取得する簡単な方法はありますか?これは複雑すぎるようです :-(
テストアドバイザーは、最後に発注された注文またはオープンポジションのすべてのデータを表示します。これは、ライブラリがこのデータを知っていることを意味します。それはイベント機能を 実装しており、ライブラリは設定されたすべてのイベントを報告します。したがって、これらのイベントを制御し、最後の注文またはポジションのオブジェクトを取得し、そこからチケット(および注文またはポジションの他のすべてのパラメータ)を取得する必要があります。まだ例を挙げることはできません。しかし、すぐに戻ってきますので、お手伝いできます。
テスト・アドバイザーがどこでイベント・データを取り、ログに出力するかは、あなた自身で見ることができる。したがって、あなたのプログラムから同じポイントにアクセスし、これらのイベントからデータを取ることができます。
В тестовых советниках же показываются все данные последнего выставленного ордера или открытой позиции.Это означает, что библиотека знает эти данные.В ней реализован событийный функционал, и о всех установленных событиях библиотека собщает.Соответственно, вам нужно контролировать эти события и получать объект последнего ордера или позиции, а из него брать тикет (и все остальные параметры ордера или позиции).Сейчас пока нет возможности привести какой-либо пример.Но в скором времени вернусь и смогу помочь
.Можете самостоятельно поглядеть откуда тестовые советники берут данные о событиях и распечатывают их в журнал.Соответственно, можете из своей программы получить доступ к той же точке и брать данные от этих событий.
テストアドバイザーは、最後に発注された注文またはオープンポジションのすべてのデータを表示します。これは、ライブラリがこのデータを知っていることを意味する。それはイベント機能を 実装しており、ライブラリはすべての設定されたイベントを報告します。したがって、これらのイベントを制御し、最後の注文またはポジションのオブジェクトを取得し、そこからチケット(および注文またはポジションの他のすべてのパラメータ)を取得する必要があります。まだ例を挙げることはできません。しかし、すぐに戻ってきますので、お手伝いできます。
テスト・アドバイザーがどこでイベント・データを取り、ログに出力するかは、あなた自身で見ることができる。従って、あなたのプログラムから同じポイントにアクセスして、これらのイベントからデータを取ることができます。
複数の注文/ポジションが要求された場合、イベントを各要求に正しく一致させるためにどのような分析を実行する必要があるのでしょうか...これらはすべて、例えば保留中の注文について ライブラリがCTradeObj::SetOrder() 内の'm_result'で受け取るチケット番号を見つけるためだけです。
というのも、 注文を出したりポジションを持ったりするとき、たいていの場合はすぐにチケット番号を記録しておき、後で参照できるようにしたいからです。私見ですが、DoEasy ユーザーにこのようなイベント処理を実装させることは、ライブラリを不必要に複雑に感じさせます 。
おそらく、あなたのアプローチにはそれなりの理由があるはずなので、あなたが同意するかどうかはわかりませんが、もし同意しないのであれば、あなたの設計決定の理由を理解することに非常に興味があります;-)
また、複数の注文/ポジションがリクエストされた場合、各リクエストとイベントを正しくマッチさせるために、どのような分析を行う必要があるのでしょ うか。
というのも、 注文を出したりポジションを持ったりするとき、たいていの場合はすぐにチケット番号を記録しておき、後で参照できるようにしたいからです。私見ですが、DoEasy ユーザーにこのようなイベント処理を実装させることは、ライブラリを不必要に複雑にします 。
おそらく、あなたのアプローチにはそれなりの理由があるはずなので、あなたが同意するかどうかはわかりませんが、もし同意しないのであれば、あなたの設計決定の理由を理解することに非常に興味があります;-)
すべては非常にシンプルだ。MQL5では、サーバーへの取引注文の 送信が成功しても、その約定が保証されるわけではありません。送信の成功は、取引注文のパラメータが正しいかどうかをチェックするためのものです。注文の執行は取引所にあります。取引環境の変化という事実を利用し、その変化を検知した上で次に進むしかない。サーバーのレスポンスで受信したデータを使用しないのはこのためです。
Всё очень просто.MQL5を使用する場合、次のようにします。Успешность отсылки - это просо проверка на корректность параметров в торговом приказе.Исполнение приказа лежит на стороне биржи.Мы можем лишь использовать факт изменения торгового окружения, и после обнаружения его изменения уже двигаться дальше.Именнопоэтой причине я не использую данные, полученные в ответе сервера.
すべてが非常にシンプルです。MQL5では、サーバーへの取引注文の 送信が成功したからといって、その約定が保証されるわけではありません。送信の成功は、取引注文のパラメータが正しいかどうかをチェックするためのものです。注文の執行は取引所にあります。取引環境の変化という事実を利用し、その変化を検知した上で次に進むしかない。サーバーのレスポンスで受信したデータを使用しないのはこのためです。
TestDoEasyPart39.mq5を 参考に、私のEAフレームワークにこのアプローチを実装し、管理を容易にしようとしています。他のEAでこれをどのように行っているか、他のコード例を教えていただけるとありがたいです。
私はまだ第39回のライブラリバージョンを使用しています。今のところ、このバージョンを使用するのがベストでしょうか、それとも新しいバージョンにアップグレードすることをお勧めしますか?
OK、TestDoEasyPart39.mq5 を参考に、私の EA フレームワークにこの方法を実装して、管理を簡単にしようとしています。他のEAでこれをどのように行っているか、他のコード例を教えていただけるとありがたいです。
私はまだ第39回のライブラリバージョンを使用しています。今のところ、このバージョンを使用するのがベストでしょうか、それとも新しいバージョンにアップグレードすることをお勧めしますか?
今のところ、それ以降のバージョンはすべてインジケーターの作成に専念しています。
すぐにアドバイザーに戻ります。そこでは、いくつかの取引イベント(同時発生)が失われたというユーザーメッセージもチェック します。
そして、ライブラリーのイベント・モデルの使い方を紹介する。
Покавсе последующие версии посвящены созданию индикаторов.
Скоро опять вернусь к советникам.Там и проверю сообщения пользователей о том, что некоторые торговые события (происходящие одновременно) теряются.
И там же смогу тогда показать как использовать событийную модель библиотеки.
これまでのところ、それ以降のバージョンはすべて指標の作成に費やされている。
すぐにアドバイザーに戻るつもりだ。そこでは、いくつかの取引イベント(同時に発生)が失われたというユーザー・メッセージもチェックするつもりだ。
そして、ライブラリーのイベント・モデルの使い方をお見せします。
エキスパート・アドバイザーの機能に再び取りかかるのはいつになりそうですか?あなたの答え次第では、少なくとも私の現在のプロジェクトでは、注文の発注やポジションのオープンなどを簡略化するための独自のマルチプラットフォーム・クラス/メソッドを書く必要があるかもしれません。
TRADE_EVENT_PENDING_ORDER_PLASEDや TRADE_EVENT_POSITION_OPENEDの ような取引イベントを処理する際、あるイベントが以前に提出した特定の取引リクエストに対応していることを確認するにはどうすればよいですか?現在、私は1つのシンボルにつき1つの注文/ポジションしか持っていないので、イベントのシンボルが私のリクエストと一致することを確認するのは簡単です。しかし、後に私のEAは同じシンボルで複数の注文/ポジションを開くことができるようになるはずです(1つのマジックナンバーを使用)。異なるマジックナンバーを使うか、マジックナンバーにグループ#1と#2をパックする機能を考えて いました。
トレードイベントをリクエストにマッチさせるには、どのようなアプローチがベストなのか、少し混乱しています。トレードリクエストとチケット番号を確実に関連付けることができれば、このプロジェクトにDoEasyを使い続けることができると思います。
エキスパート・アドバイザーの機能については、いつ再開する予定ですか?あなたの答え次第では、注文の発注やポジションのオープンなどを簡略化するために、独自のマルチプラットフォーム・クラス/メソッドを書く必要があるかもしれません。
TRADE_EVENT_PENDING_ORDER_PLASEDや TRADE_EVENT_POSITION_OPENEDの ような取引イベントを処理する際、あるイベントが以前に提出した特定の取引リクエストに対応していることを確認するにはどうすればよいですか?現在、私はシンボルごとに1つの注文/ポジションしか持っていないので、イベントのシンボルが私のリクエストと一致することを確認するのは簡単です。しかし、後に私のEAは同じシンボルで複数の注文/ポジションを開くことができるようになるはずです(1つのマジックナンバーを使用)。異なるマジックナンバーを使うか、グループ#1と#2をマジックナンバーにパックする機能を考えて いました。
トレードイベントをリクエストにマッチさせるには、どのようなアプローチがベストなのか、少し混乱しています。トレードリクエストとチケット番号を確実に関連付けることができれば、このプロジェクトでDoEasyを使い続けることができると思います。