int ticket;while(true){
ticket=OrderSend(Symbol(),OP_BUY,1.0,Ask,3,0,0,"комментарий эксперта",255,0,CLR_NONE);if( ticket<=0){......RefreshRates();}else{.....}}
1- 信号受信-実行フラグセット //信号チェック関数が順序設定関数を渡す 2-refresh() テイクオフを計算 //価格との整合性をチェック - シグナルの価格（まだアクティブであれば）。 3-entry //calculation of takeoffs is static in OrderSend function, stop in OrderModify function 4-サーバー拒否 //注文が出ず、シグナルがあった場合、シグナルの価格で再エントリー（まだ有効であれば）。 5-エラーを解読する //新たな問題が発生した場合に備えて、自分用に必要です 6信号がまだ有効である - 実行するフラグ？//condition of price match - signalからの価格(まだ有効であれば)。 7-ステップ1へ //ステップ3へ
RefreshRates()関数を正しく使うには？
また、フォーラムで「ERROR: code=138- requote」を読みました。
テスターで "OrderSend error 138 "が1秒間に何度も発生するのですが、これはリクオートでしょうか？もしそうなら、どうやって戦うのか）？
リクオートのスレッドを20個も読んだら・・・。自分のミスが何だったのかやっとわかった)
疑似」リクオートをしました。理由は、エントリー条件が発動されたため、価格が.NETに送られたためです。実際には、.NETで発表された価格よりも、実際の価格は安かったり高かったりした。OrderSendが 注文を開こうとするたびに、当然ながらエラー138が発生しました。
解決策は、OrderSendの前に、実際の価格とシグナルで渡された価格が等しいかどうかをチェックすることでした)
残るはOrderModifyオーダーのエラーチェックです。
OrderSendのチェックは必要ないと思います、シグナルで与えられた価格でパルスを打たせてください）もしrequoteが来ても問題ありません、私は買うか売るかの時間があります。重要なのは、すべてが計画通りに動くことです)
リクオートのスレッドを20個も読んだら・・・。自分のミスが何だったのかやっとわかった)
疑似」リクオートをしました。原因は、エントリー条件が発動したため、OrderSendに価格が渡されてしまったことです。そして現実には、OrderSendで入力した価格よりも、実際の価格が安かったり高かったりしたのです。OrderSendが注文を開こうとするたびに、エラー138が発生しました。
解決策は、OrderSendの前に、実際の価格がシグナルによって渡された価格と等しいかどうかをチェックすることでした。）
OrderModify オーダーのエラーをチェックする必要があります。
OrderSendをチェックする必要はなく、シグナルが設定した価格で脈を打つようにすればいいと思います）もしrequoteが来ても問題ないでしょう、売買する時間はあります。重要なのは、すべてが計画通りに動くことです)
RefreshRates()。
Ask Bidにアクセスする前にやっておくと便利なこと
ストップとエントリー価格を計算するブロックの前に、すべての売指値または買指値を確認したい場合 - 現在の価格に基づいて計算されていない場合、ロングレンジの保留注文は影響を受けない場合があります。
RefreshRates()。
Ask Bidにアクセスする前に行っておくと便利です。
それは、私がやったことではないのか...ビッドの前に
ストップ・テイクとエントリー価格を計算するブロックの前 - 長距離注文は、現在の価格で計算されない場合、影響を受けないかもしれません。
それは私がやったことではないのか...Bidに変わる前に
>>説明してください。では、私の場合、カウントではなく、比較なので、ここでは必要ないのでしょうか？私の読みは正しいのでしょうか？
あなたは正しいことをしたのです :-)
そこそこ問題ないです!
ただ、価格にアクセスするブロックは、できれば一カ所にまとめておきたい。
を適用する前に、このコマンドがあることが望ましい。
Bid Askにアドレスし、すべてのストップを計算した後、それほど遅れることなく市場に参入しなければならない。
---
これをコードに追加します。
かんたんにいえば
1 - 信号を受信 - 実行フラグを設定します。
2refresh() 持ち帰り用ストップを計算する
3イン
4サーバ拒否
5-デコードエラー
6-信号がまだアクティブである-実行フラグが設定されていますか？
7- ポイント1へ
そして、このサイクルを断ち切ることが必要なのです
長くなるので
が、私たちは
1-エラー判定
2 - サイクルが求めるほど長くはないディーラーを叩くようにしてください。
2.1例えば、何回叩いたかをカウントすることができます。
2.2 量子的な時間ができる
2.3 実行するコマンドを発行する前に、信号があるかどうかを把握しなければならない!
とか、キャンセルしたほうがいいのでは！？
...ただ、できれば価格にアクセスするブロックは一箇所にまとめて欲しいところです
を呼び出す前に、このコマンドがあることが望ましい。
Bid Askに行き、すべてのストップを計算し、遅滞なくマーケットに入る...。
一箇所に...よくわからないんだけど...。インジケータを長くしているのですが、ループが完成しません（泣)
こんな感じで持っています。
-シグナルをチェックする関数UpTrend()およびDownTrend()によって、エントリーする価格が定義されます。
-シグナルからの価格とのパリティをチェックする（場合）。
-入力する価格と価格はOrderSendで処理されます。
-逆指値はOrderSendに続くModifyPos()関数で処理されます。
1- 信号受信-実行フラグセット //信号チェック関数が順序設定関数を渡す
2-refresh() テイクオフを計算 //価格との整合性をチェック - シグナルの価格（まだアクティブであれば）。
3-entry //calculation of takeoffs is static in OrderSend function, stop in OrderModify function
4-サーバー拒否 //注文が出ず、シグナルがあった場合、シグナルの価格で再エントリー（まだ有効であれば）。
5-エラーを解読する //新たな問題が発生した場合に備えて、自分用に必要です
6信号がまだ有効である - 実行するフラグ？//condition of price match - signalからの価格(まだ有効であれば)。
7-ステップ1へ //ステップ3へ
そして、このサイクルを断ち切らなければならないのです。
かなり長くなる可能性がある //価格=シグナルの価格である限り、私はそうは思わないが、頻繁にあるかもしれない)
が、私たちは
1-エラーの判定 //今日から頑張ろうかな。
2-tryは、ディーラーが長くはない//価格==信号の価格であるべきであるようにバングする。
2.1.何回ロングにすればいいかカウンターを作ることができる // 考えなければならない、テスターで履歴を確認することができる
2.2 量子でできる //価格=信号の価格(まだ有効なら)を見逃す可能性がある
2.3 各シリーズの実行を指示する前に、シグナルがあるかどうかを確認しなければならない!
シグナルをキャンセルするタイミングかもしれない //シグナルチェック機能が注文設定機能をパスする
OrderModifyを正しく実装する方法がわからないのですが？これがないとストップが設定できない...開くとDC制限...。
- は、オープン後に価格が変化して近づいた場合、130のエラーが発生することがあります。
-再指値エラー138が発生し、価格が上昇し、ストップが全く設定されない可能性があります。
-138のリクオートで価格が下がる可能性がありますが、これはストップが後で設定されるので重要ではありません。
それで...
このバリアントのデメリットは
-価格が建値より 下に移動した場合、ストップは設定されません。
価格が建値より低くなった場合、ストップは決して置かれません - 常に注文を修正しようとします。それとも、そうならないのか？
くらい...
この機種のデメリット
-価格が反対に動いた場合、多くのエラーが発生します。
とりあえずストップでこのオプションを検討中、セットアップまで置く)
しかし、ModifyB; ModifyBと ある行でエラーが発生します。
- ';' - 変数がすでに定義されている
- ';' - 変数がすでに定義されている
もう一つの選択肢ですが、これもエラーになります(
もう一つの選択肢ですが、これもエラーになります(