複数の注文を同時に決済することは可能ですか? - ページ 7 1234567 新しいコメント hrenfx 2010.09.06 12:11 #61 TheXpert: 逆に、なぜMT5がコマンドの同期実行から離れたのか不思議です。 。 取引注文の 非同期処理は、イベントを通じてJForex APIに完璧に実装されています(取引要求のそれぞれについて何が起こったか、なぜそうなったかを正確に知ることができます)。そこでも各取引要求には、状態(作成済み(作成したがサーバーに送信していない(通信に失敗したなど))、配信済み(サーバーが受理した)、進行中、実行済み)のフラグが立っています。MQL5では、ちょうど今、それをやろうとしているところです。そして、開発者の行動から判断すると、どうすればより良くできるのかわからないというのが現状です。 非同期性自体は論理的なものです。異なるシンボルでの取引は独立して行われます。しかし、1つの取引商品での非同期は市場の定義上ありえません。もちろん、MT4サーバーでは、1つの取引商品で非同期が発生することがありますが、それは市場とは言えません。 削除済み 2010.09.06 12:12 #62 TheXpert:さて、さて...5でもそれはないだろう。開発者にとっても、99%のユーザーにとっても、殺人的なことです。開発者にとっては殺人ではありません。アプリケーション・オブジェクトのロジックとしてはごく普通のもので、簡単に設計・実装できる。 また、アプリケーションについても、現在と同じような機能で、かつ複雑でないものを設計できる可能性があります。しかし、誰がそれを処理するのでしょうか?開発者には、そのようなスタッフはいません。 そのため、ユーザー側、つまり私や皆さんはプロフェッショナルではなく、最低限の複雑さも許さない人がほとんどであり、メタクオートによるこのような機能の実装につながるという問題があるのです。 TheXpert 2010.09.06 12:18 #63 hrenfx: 非同期取引注文処理は、イベントを通じてJForex APIに完璧に実装されています(取引要求のそれぞれについて何が起こり、なぜそうなったのかを正確に把握することができます)。そこでも各取引要求には、状態(作成済み(作成したがサーバーに送信していない(通信に失敗したなど))、配信済み(サーバーが受け入れた)、進行中、実行済み)のフラグが立っています。MQL5では、ちょうど今、それをやろうとしているところです。そして、開発者の行動から判断すると、どうすればより良いものができるのかわからないのです。 現在5で実装されているやり方は非論理的だと思います。 ジップ です。 開発者にとっては、キラーではないのです。これは、ごく普通の応用ロジックで、簡単に設計・実装できます。 まあ、上のような書き方なら当然ですが。 1234567 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
逆に、なぜMT5がコマンドの同期実行から離れたのか不思議です。 。
取引注文の 非同期処理は、イベントを通じてJForex APIに完璧に実装されています(取引要求のそれぞれについて何が起こったか、なぜそうなったかを正確に知ることができます)。そこでも各取引要求には、状態(作成済み(作成したがサーバーに送信していない(通信に失敗したなど))、配信済み(サーバーが受理した)、進行中、実行済み)のフラグが立っています。MQL5では、ちょうど今、それをやろうとしているところです。そして、開発者の行動から判断すると、どうすればより良くできるのかわからないというのが現状です。
非同期性自体は論理的なものです。異なるシンボルでの取引は独立して行われます。しかし、1つの取引商品での非同期は市場の定義上ありえません。もちろん、MT4サーバーでは、1つの取引商品で非同期が発生することがありますが、それは市場とは言えません。
さて、さて...5でもそれはないだろう。開発者にとっても、99%のユーザーにとっても、殺人的なことです。
開発者にとっては殺人ではありません。アプリケーション・オブジェクトのロジックとしてはごく普通のもので、簡単に設計・実装できる。
また、アプリケーションについても、現在と同じような機能で、かつ複雑でないものを設計できる可能性があります。しかし、誰がそれを処理するのでしょうか?開発者には、そのようなスタッフはいません。
そのため、ユーザー側、つまり私や皆さんはプロフェッショナルではなく、最低限の複雑さも許さない人がほとんどであり、メタクオートによるこのような機能の実装につながるという問題があるのです。
非同期取引注文処理は、イベントを通じてJForex APIに完璧に実装されています(取引要求のそれぞれについて何が起こり、なぜそうなったのかを正確に把握することができます)。そこでも各取引要求には、状態(作成済み(作成したがサーバーに送信していない(通信に失敗したなど))、配信済み(サーバーが受け入れた)、進行中、実行済み)のフラグが立っています。MQL5では、ちょうど今、それをやろうとしているところです。そして、開発者の行動から判断すると、どうすればより良いものができるのかわからないのです。
現在5で実装されているやり方は非論理的だと思います。
開発者にとっては、キラーではないのです。これは、ごく普通の応用ロジックで、簡単に設計・実装できます。