デベロッパーズ!作ったものをテストしたりもするのですか？ - ページ 5 123456789101112...19 新しいコメント Yury Kulikov 2013.12.10 10:42 #41 Mikalas:簡単な2つの質問にお答えください。1.取引が成立した場合、TRADE_TRANSACTION_DEAL_ADD -->ORDER_STATE_STARTED を取得すべきかどうか？2.注文が変更された旨のメッセージの後 TRADE_TRANSACTION_ORDER_UPDATE --> ORDER_STATE_REQUEST_MODIFYTRADE_TRANSACTION_ORDER_UPDATE --> ORDER_STATE_PLACED のメッセージが表示されるかどうか?私宛の質問ではありませんが、回答させていただきます :)イベントを扱うということは、例えば、乗り換えで迷子になるとか、キューで待てないとか、期待した出来事が起きない可能性があるということであり、ごくごく稀にしか起きない（端末のバグも含む）のである。だから、イベントモデルを確実に動作させるためのバックアップが必要なのです。例えば、私は特に重要なイベントのためにウェイティングリストを作り、関連するイベントだけでなく、期待されるイベントが起こったことを間接的に確認することによって、それをコントロールします。 Artyom Trishkin 2013.12.10 10:44 #42 Mikalas:アルテム、あなたの言葉を鵜呑みにするつもりはありませんが、それは 意図的なものなのですね。実は、現在のバグではは、私のTORに従ってEAを 書くことを許さないでしょう。現在、私のExpert Advisorは動作しており、1日あたり1％の利益をもたらしています。徹底的にバージョンアップしたかったのですが、バグがあるためMT-5エラーは動作しません。また、5000ユーロのデポでテストする場合、初期費用はどのくらいになるのでしょうか？私はいつも予備知識を入れています。私の予備的な条件に同意した後、私はToRを読み、そして言う - それはより少ないコストになるだろう/より高価になるだろう/現実的ではありません。合意後、ToRを細部に至るまで議論します。そして、完全に相互理解をした上で、仕事をする意思を確認します。作業中は、お客様と密接に連携しています。いつも連絡を取り合っている。アルゴリズムの「歯車」の一つひとつについて、議論と解明を続けています。次の「歯車」が磨かれ、テストされるまでは、次の歯車には進めません。最終的な解を渡す前に、私自身はテスターで、アルゴリズムの正しさだけをテストします。アカウントでのテスト - バグに対してのみ、お客様の費用負担で行います。何でもない話だと理解しています。早く終わらせよう。 Artyom Trishkin 2013.12.10 10:46 #43 Mikalas:P/S どのような高級言語を使っているのですか？もう「ションベン大会」を始めてしまったのでしょうか？悪態をつくと言うことです。 Mikhail Filimonov 2013.12.10 10:48 #44 ユーリさん、こんにちは。そうですね、もちろんおっしゃるとおり、イベントは一度だけでなく、二度、三度とやってくるかもしれません。でも、来るけど、OTHER!注文が変更されたことを（サーバーからの応答なしに）どのように制御しているか教えていただけませんか？ Mikhail Filimonov 2013.12.10 10:52 #45 artmedia70:もう「ションベン大会」を始めてしまったのでしょうか？答えています-汚い言葉で。 アルチョム、質問に対してひねくれた理解をしている!単純に、（アドバイザーの代わりに）書いていただくのはアリだと思いました。プラザIIの小型端末を（アドバイザーの代わりに）書いてもらえないかと思っただけです、難しいでしょうけど...。 Artyom Trishkin 2013.12.10 10:59 #46 Mikalas:アルチョムさん、質問に対してひねくれた理解をしていますね～。ただ、（アドバイザーの代わりに）執筆を依頼することは可能だと思いました。プラザIIの小型端末を（アドバイザーの代わりに）書いてもらえないかと思っただけです、一人では難しいでしょうから...。申し訳ありません。私はあなたを間違って理解していました。疲れが影響しているのか、複雑なオーダーをこなしているのにあまり眠れない......。ご提案ありがとうございました。私の計画は少し変わっています。パスしようかな。 Vasiliy Sokolov 2013.12.10 11:08 #47 Yurich:私宛の質問ではありませんが、回答させていただきます :)イベントを扱うということは、例えば途中で迷子になるとか、キューが待てないとか、期待した出来事が起きない可能性があり、（端末のバグも含めて）ごくわずかなことが起きる可能性があるということです。だから、イベントモデルを確実に動作させるためのバックアップが必要なのです。例えば、非常に重要なイベントには待ち行列を作り、関連するイベントだけでなく、期待されるイベントが起こったことを間接的に確認することで、待ち行列をコントロールしています。いいえ、うまくいきません。イベントモデルは 絶対に信頼できるものでなければならない。イベントが届かなければ、それはなかったことになる。FORTSでは、注文の変更によって何十もの取引が発生するため、イベントを特に明確に実行する必要があります。ミカラス： こちらこそ、ありがとうございました。"プラザII "へ。 おすすめしません。このバグをMQで修正するのは、自分でPlaza用の端末を新しく作るよりずっと簡単です。バグを延々と修正したり、「標準機能」を書いたりして、泥沼にはまる。自分の経験から言っているんです。ストック#をベースにした自作複合機を部分的に開発し、特定の作業を行うためのもう一つの「自転車」を完成させました。サポートサービスと一緒に戦ったほうが、楽だし、安上がりだよ。 Anatoli Kazharski 2013.12.10 11:09 #48 Mikalas:ユーリさん、こんにちは。そうですね、もちろんおっしゃるとおり、イベントは一度だけでなく、二度、三度とやってくるかもしれません。でも、来るけどOTHER回!とはいえ、その1回、2回、3回が、最も都合の悪い時にやってくるかもしれません。ちなみにヘルプには、このことが詳しく書かれています。開発者は、ある取引が他の取引の後に到着するのを待つような取引アルゴリズムを構築 することを推奨していません。端末から手動で送信された 1 つの取引要求、またはOrderSend()/OrderSendAsync() 関数によって、取引サーバに複数の連続した取引が発生します。これらの取引の端末への到着順序は保証されていないため、ある取引取引の到着を他の取引より後に待つという取引アルゴリズムを構築することはできません。また、サーバーから端末に配信する際に、トランザクションが失われる可能性がある。//---注文が変更された場合（サーバーからの応答がない場合）、どのように制御するのか、教えてください。例えば、以前の値と現在の値を比較する。 Yury Kulikov 2013.12.10 11:28 #49 C-4:いいえ、うまくいきません。イベントモデルは絶対に信頼できるものでなければならない。そこにイベントが届かなかったら、それはなかったことになる。FORTSでは、注文の変更によって何十もの取引が発生するため、イベントを特に正確に実行する必要があります。イベント駆動型 モデルは、その定義上、絶対的な信頼性を確保することはできません。イベントがそこに到達しなかったとしても、それが起こらなかったということにはならないのです。 Mikhail Filimonov 2013.12.10 11:32 #50 tol64!はい、どのように来てもかまいません（ただし、「注文が入った」イベントが先に来て、その後に「注文が変更された状態」が来るのは論理的ではありません）。違うか？私の写真をよく見ると、「注文が成立しました」ではなく、「注文が一部成立しました」というメッセージが来ていますね（2つ並んでいます）！？P/S そして、「本文を破り捨てる」ことも、そんな風に始まる文章も全部必要ない。取引の種類を知ること で、取引口座の注文、ポジション、取引の現在の状況を分析することを決定できます。 123456789101112...19 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
簡単な2つの質問にお答えください。
1.取引が成立した場合、TRADE_TRANSACTION_DEAL_ADD -->ORDER_STATE_STARTED を取得すべきかどうか？
2.注文が変更された旨のメッセージの後 TRADE_TRANSACTION_ORDER_UPDATE --> ORDER_STATE_REQUEST_MODIFY
TRADE_TRANSACTION_ORDER_UPDATE --> ORDER_STATE_PLACED のメッセージが表示されるかどうか?
私宛の質問ではありませんが、回答させていただきます :)
イベントを扱うということは、例えば、乗り換えで迷子になるとか、キューで待てないとか、期待した出来事が起きない可能性があるということであり、ごくごく稀にしか起きない（端末のバグも含む）のである。だから、イベントモデルを確実に動作させるためのバックアップが必要なのです。例えば、私は特に重要なイベントのためにウェイティングリストを作り、関連するイベントだけでなく、期待されるイベントが起こったことを間接的に確認することによって、それをコントロールします。
アルテム、あなたの言葉を鵜呑みにするつもりはありませんが、それは
意図的なものなのですね。実は、現在のバグでは
は、私のTORに従ってEAを 書くことを許さないでしょう。
現在、私のExpert Advisorは動作しており、1日あたり1％の利益をもたらしています。
徹底的にバージョンアップしたかったのですが、バグがあるため
MT-5エラーは動作しません。
また、5000ユーロのデポでテストする場合、初期費用はどのくらいになるのでしょうか？
私はいつも予備知識を入れています。私の予備的な条件に同意した後、私はToRを読み、そして言う - それはより少ないコストになるだろう/より高価になるだろう/現実的ではありません。合意後、ToRを細部に至るまで議論します。そして、完全に相互理解をした上で、仕事をする意思を確認します。作業中は、お客様と密接に連携しています。いつも連絡を取り合っている。アルゴリズムの「歯車」の一つひとつについて、議論と解明を続けています。次の「歯車」が磨かれ、テストされるまでは、次の歯車には進めません。最終的な解を渡す前に、私自身はテスターで、アルゴリズムの正しさだけをテストします。アカウントでのテスト - バグに対してのみ、お客様の費用負担で行います。
何でもない話だと理解しています。早く終わらせよう。
P/S どのような高級言語を使っているのですか？
もう「ションベン大会」を始めてしまったのでしょうか？
悪態をつくと言うことです。
ユーリさん、こんにちは。
そうですね、もちろんおっしゃるとおり、イベントは一度だけでなく、二度、三度とやってくるかもしれません。
でも、来るけど、OTHER!
注文が変更されたことを（サーバーからの応答なしに）どのように制御しているか教えていただけませんか？
もう「ションベン大会」を始めてしまったのでしょうか？
答えています-汚い言葉で。
アルチョム、質問に対してひねくれた理解をしている!
単純に、（アドバイザーの代わりに）書いていただくのはアリだと思いました。
プラザIIの小型端末を（アドバイザーの代わりに）書いてもらえないかと思っただけです、難しいでしょうけど...。
アルチョムさん、質問に対してひねくれた理解をしていますね～。
ただ、（アドバイザーの代わりに）執筆を依頼することは可能だと思いました。
プラザIIの小型端末を（アドバイザーの代わりに）書いてもらえないかと思っただけです、一人では難しいでしょうから...。
申し訳ありません。私はあなたを間違って理解していました。疲れが影響しているのか、複雑なオーダーをこなしているのにあまり眠れない......。
ご提案ありがとうございました。私の計画は少し変わっています。パスしようかな。
私宛の質問ではありませんが、回答させていただきます :)
イベントを扱うということは、例えば途中で迷子になるとか、キューが待てないとか、期待した出来事が起きない可能性があり、（端末のバグも含めて）ごくわずかなことが起きる可能性があるということです。だから、イベントモデルを確実に動作させるためのバックアップが必要なのです。例えば、非常に重要なイベントには待ち行列を作り、関連するイベントだけでなく、期待されるイベントが起こったことを間接的に確認することで、待ち行列をコントロールしています。
いいえ、うまくいきません。イベントモデルは 絶対に信頼できるものでなければならない。イベントが届かなければ、それはなかったことになる。FORTSでは、注文の変更によって何十もの取引が発生するため、イベントを特に明確に実行する必要があります。
こちらこそ、ありがとうございました。
"プラザII "へ。
おすすめしません。このバグをMQで修正するのは、自分でPlaza用の端末を新しく作るよりずっと簡単です。バグを延々と修正したり、「標準機能」を書いたりして、泥沼にはまる。自分の経験から言っているんです。ストック#をベースにした自作複合機を部分的に開発し、特定の作業を行うためのもう一つの「自転車」を完成させました。サポートサービスと一緒に戦ったほうが、楽だし、安上がりだよ。
ユーリさん、こんにちは。
そうですね、もちろんおっしゃるとおり、イベントは一度だけでなく、二度、三度とやってくるかもしれません。
でも、来るけどOTHER回!
とはいえ、その1回、2回、3回が、最も都合の悪い時にやってくるかもしれません。ちなみにヘルプには、このことが詳しく書かれています。開発者は、ある取引が他の取引の後に到着するのを待つような取引アルゴリズムを構築 することを推奨していません。
端末から手動で送信された 1 つの取引要求、またはOrderSend()/OrderSendAsync() 関数によって、取引サーバに複数の連続した取引が発生します。これらの取引の端末への到着順序は保証されていないため、ある取引取引の到着を他の取引より後に待つという取引アルゴリズムを構築することはできません。また、サーバーから端末に配信する際に、トランザクションが失われる可能性がある。
//---
注文が変更された場合（サーバーからの応答がない場合）、どのように制御するのか、教えてください。
例えば、以前の値と現在の値を比較する。
いいえ、うまくいきません。イベントモデルは絶対に信頼できるものでなければならない。そこにイベントが届かなかったら、それはなかったことになる。FORTSでは、注文の変更によって何十もの取引が発生するため、イベントを特に正確に実行する必要があります。
イベント駆動型 モデルは、その定義上、絶対的な信頼性を確保することはできません。イベントがそこに到達しなかったとしても、それが起こらなかったということにはならないのです。
tol64!
はい、どのように来てもかまいません（ただし、「注文が入った」イベントが先に来て、その後に「注文が変更された状態」が来るのは論理的ではありません）。
違うか？
私の写真をよく見ると、「注文が成立しました」ではなく、「注文が一部成立しました」というメッセージが来ていますね（2つ並んでいます）！？
P/S そして、「本文を破り捨てる」ことも、そんな風に始まる文章も全部必要ない。
取引の種類を知ること で、取引口座の注文、ポジション、取引の現在の状況を分析することを決定できます。