ダニの話 - ページ 24 1...17181920212223242526 新しいコメント Vladimir Karputov 2016.06.08 07:44 #231 juriy5555:ティックインジケータのクエリから判断すると、time_mskフィールドのデータは1000の倍数である。つまり、ミリ秒の話ではなく、1秒の解像度の話です。 質問:では、MqlTickの構造を 拡張する意味は何だったのでしょうか? また、接続したトレードサーバーは何ですか? juriy5555 2016.06.08 15:48 #232 Openbrokerのデモとリアル口座も持っています。本番では、すべてのAccessサーバーで同じ結果が得られます。まあ、デモでも同じなのですが。Si-6.16、RTS-6.16、SBRF-6.16を見ましたが、すべて1000の倍数で変化しています。 あなたのところではそうではないのですか? Slava 2016.06.08 16:00 #233 juriy5555: 私はOpenbrokerのDemoと同じ場所にリアル口座を持っています。実際のすべてのAccessサーバーで同じ結果が得られますが、デモでも同じです。Si-6.16、RTS-6.16、SBRF-6.16を見ましたが、すべて1000の倍数になっています。 そうではありませんか?現在、SymbolInfoTickクエリは、実際のミリ秒(1000の倍数)ではなく、MqlTick構造 体にゼロを返します。次のビルドまでお待ちください。PS on request CopyTicks ミリ秒をそのまま付与する。 juriy5555 2016.06.08 16:17 #234 このスレッドからこのインジケータをダウンロードしてテストしてみました。CopyTicksを介して過去30ティックを正確に取得します。あるいは、別のサーバー(openbrokerではない)で試してみるべきかもしれません。>>"実際のミリ秒の代わりにゼロが与えられて いる"。ゼロは出さず、常に1000の倍数の同じ数字を出す。(...2064, ...2064, ...3064, ..., ..., ..4064 ) ファイル: copyticksind.mq5 6 kb Slava 2016.06.08 16:39 #235 juriy5555:このスレッドからこのインジケータをダウンロードしてテストしてみました。CopyTicksを介して過去30ティックを正確に取得します。あるいは、別のサーバー(openbrokerではない)で試してみるべきかもしれません。>>"実際のミリ秒の代わりにゼロが与えられて いる"。ゼロは出さず、常に1000の倍数の同じ数字を出す。(...2064, ...2064, ...3064, ..., ..., ..4064 )ゼロはSymbolInfoTick関数で 渡されます。CopyTicksでは、実際のミリ秒が指定されます。これが2064、3064、4064となれば、そうであったということになる。なぜそうなったのか、それはわからない。あなたのコードに目を通しました。4dの出力指定は? time_mscが長いので、dだけではうまくいきません。I64dのはずです。 juriy5555 2016.06.08 17:14 #236 Slawa:ゼロは、SymbolInfoTick関数で 与えられる。CopyTicksでは、実際のミリ秒が指定されます。2064年、3064年、4064年なら、そうだったんですね。なぜそうなったのか、それはわからない。あなたのコードに目を通しました。4dの出力指定は? time_mscが長いので、dだけではうまくいきません。I64dのはずです。はい、すみません。コードは私のものではありません。このコードの作者は本当にStringFormatにスレがあるんですね。ループの各反復で Print (tick.time_msc) を通してプリントしました。その結果、最後にはすべてゼロになり、やはりミリ秒は得られない。CopyTicks リクエストは持続する。 ファイル: 99999.jpg 332 kb Vladimir Karputov 2016.06.08 17:16 #237 Slawa:ゼロは、SymbolInfoTick関数で 与えられる。CopyTicksでは、実際のミリ秒が指定されます。2064年、3064年、4064年なら、そうだったんですね。なぜそうなったのか、それはわからない。あなたのコードを見ました。出力指定子 %-4d とは何ですか? time_msc は長いので、d だけではうまくいきません。I64dのはずです。最初の投稿からインジケータを変更 - StringFormatを弄らない、今はそのようになっているはずです。string tick_string=IntegerToString(i,2,'0')+" "+TimeToString(tick.time,TIME_MINUTES|TIME_SECONDS)+" "+ DoubleToString(tick.bid,Digits())+" "+DoubleToString(tick.ask,Digits())+" "+ DoubleToString(tick.last,Digits())+" "+IntegerToString(tick.volume,7,'0')+" "+ IntegerToString(tick.time_msc,19,'0')+" "+IntegerToString(tick.flags,2,'0'); Slava 2016.06.08 17:27 #238 juriy5555:はい、すみません。コードは私のものではありません。作者は本当にStringFormatにバグがあるんですね。ループの各反復で (tick.time_msc) を表示します。その結果、最後にはすべてゼロになり、やはりミリ秒は得られない。リクエストのCopyTicksはずっと行って います。MetaQuotesのデモデータでのインジケーターはこちらです。ティックにミリ秒がないことについては、ブローカーにお尋ねください。 juriy5555 2016.06.08 17:32 #239 Slawa:MetaQuotesのデモデータでのインジケーターはこちらです。ティックにミリ秒がないことについては、ブローカーにお尋ねください まだ、何を誰に書けばいいのかわからない、数ヶ月の間。やはりOpenBrokerがサーバーを更新してくれることを期待します。 ps my client build 1340 削除済み 2016.06.09 14:34 #240 juriy5555 : Пока не знаю, что и у кому конкретно писать, я в этом несколько месяцев. Буду надеяться, что ОпенБрокер всё таки обновит сервер. ps мой билд клиента 1340少し違う計画ですが、質問もありますし、ダニから伝わる情報が正しいのかと思います。実際のボリュームについての質問。インジケーターからティックに関する情報を要求すると、実際のボリュームはvolume[]配列に入れられます。また、理論的には、ティックから情報を取得する場合、キャンドルごとに累積されるボリュームは、volume[]配列の値と一致する必要があります。テストコードの例を次に示します。 //+------------------------------------------------------------------+ //| Custom indicator initialization function | //+------------------------------------------------------------------+ int OnInit () { //--- indicator buffers mapping //--- return ( INIT_SUCCEEDED ); } //+------------------------------------------------------------------+ //| Custom indicator iteration function | //+------------------------------------------------------------------+ int OnCalculate ( const int rates_total, const int prev_calculated, const datetime &time[], const double &open[], const double &high[], const double &low[], const double &close[], const long &tick_volume[], const long &volume[], const int &spread[]) { //--- Получение данных по тику MqlTick tick; // Структура хранения инфо по тику SymbolInfoTick ( _Symbol ,tick ); // Получение данных по тику Print ( "ask: " + DoubleToString (tick.ask, _Digits )+ ", bid: " + DoubleToString (tick.bid, _Digits )+ ", last: " + DoubleToString (tick.last, _Digits )+ ", vol: " ,tick.volume, ", flags: " ,tick.flags); //--- Формирование объема static ulong sVol; // Суммарный объем из тиков на свече if (prev_calculated<= 0 ) // Если первый запуск sVol=tick.volume; // Запоминаем значение тика else { if (rates_total>prev_calculated) // Если образовалась новая свеча { sVol=tick.volume; // Запоминаем значение объема первого тика } else // Если новая свеча не образовалась sVol+=tick.volume; // Суммируем объем тика с накопленным объемом } Print ( "Реальный объем: " ,volume[rates_total- 1 ], ", накопленный объем: " ,sVol); //--- return (rates_total); } //+------------------------------------------------------------------+今のところフラグに執着せず、受信した各ティックがsVolの合計ボリュームを変更すると仮定します(ただし、私が知る限り、これは当てはまりません)。新しいキャンドルの形成を待っており、ジャーナルのエントリを確認します。ブローカーオープニング、リアルアカウント、ビルド1340、RTS-6.16: 2016.06 . 09 17 : 07 : 01.820 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 1 , накопленный объем: 1 2016.06 . 09 17 : 07 : 03.142 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94670 , bid: 94660 , last: 94670 , vol: 3 , flags: 24 2016.06 . 09 17 : 07 : 03.142 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 1 , накопленный объем: 4 2016.06 . 09 17 : 07 : 03.142 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94670 , bid: 94660 , last: 94670 , vol: 3 , flags: 24 2016.06 . 09 17 : 07 : 03.142 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 5 , накопленный объем: 7 2016.06 . 09 17 : 07 : 03.142 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94670 , bid: 94660 , last: 94670 , vol: 3 , flags: 24 2016.06 . 09 17 : 07 : 03.142 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 7 , накопленный объем: 10 2016.06 . 09 17 : 07 : 03.142 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94670 , bid: 94660 , last: 94670 , vol: 3 , flags: 24 2016.06 . 09 17 : 07 : 03.142 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 8 , накопленный объем: 13 2016.06 . 09 17 : 07 : 03.142 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94670 , bid: 94660 , last: 94670 , vol: 3 , flags: 24 2016.06 . 09 17 : 07 : 03.142 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 11 , накопленный объем: 16 2016.06 . 09 17 : 07 : 03.266 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94670 , bid: 94660 , last: 94670 , vol: 1 , flags: 0 2016.06 . 09 17 : 07 : 03.266 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 16 , накопленный объем: 17 2016.06 . 09 17 : 07 : 03.266 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94670 , bid: 94660 , last: 94670 , vol: 1 , flags: 0 2016.06 . 09 17 : 07 : 03.266 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 18 , накопленный объем: 18 2016.06 . 09 17 : 07 : 03.266 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94670 , bid: 94660 , last: 94670 , vol: 1 , flags: 0 2016.06 . 09 17 : 07 : 03.266 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 19 , накопленный объем: 19 2016.06 . 09 17 : 07 : 03.700 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94670 , bid: 94660 , last: 94660 , vol: 1 , flags: 24 2016.06 . 09 17 : 07 : 03.700 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 20 , накопленный объем: 20 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94660 , last: 94680 , vol: 1 , flags: 0 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 22 , накопленный объем: 21 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94660 , last: 94680 , vol: 1 , flags: 0 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 27 , накопленный объем: 22 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94660 , last: 94680 , vol: 1 , flags: 0 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 28 , накопленный объем: 23 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94660 , last: 94680 , vol: 1 , flags: 0 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 29 , накопленный объем: 24 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94660 , last: 94680 , vol: 1 , flags: 0 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 31 , накопленный объем: 25 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94660 , last: 94680 , vol: 1 , flags: 0 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 33 , накопленный объем: 26 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94660 , last: 94680 , vol: 1 , flags: 0 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 38 , накопленный объем: 27 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94660 , last: 94680 , vol: 1 , flags: 0 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 43 , накопленный объем: 28 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94660 , last: 94680 , vol: 1 , flags: 0 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 45 , накопленный объем: 29 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94660 , last: 94680 , vol: 1 , flags: 0 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 47 , накопленный объем: 30 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94660 , last: 94680 , vol: 1 , flags: 0 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 49 , накопленный объем: 31 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94660 , last: 94680 , vol: 1 , flags: 0 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 51 , накопленный объем: 32 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94660 , last: 94680 , vol: 1 , flags: 0 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 56 , накопленный объем: 33 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94660 , last: 94680 , vol: 1 , flags: 0 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 59 , накопленный объем: 34 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94660 , last: 94680 , vol: 1 , flags: 0 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 60 , накопленный объем: 35 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94660 , last: 94680 , vol: 1 , flags: 0 2016.06 . 09 17 : 07 : 04.319 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 60 , накопленный объем: 36 2016.06 . 09 17 : 07 : 04.347 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94670 , last: 94670 , vol: 1 , flags: 0 2016.06 . 09 17 : 07 : 04.347 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 61 , накопленный объем: 37 2016.06 . 09 17 : 07 : 04.347 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94670 , last: 94670 , vol: 1 , flags: 0 2016.06 . 09 17 : 07 : 04.347 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 61 , накопленный объем: 38 2016.06 . 09 17 : 07 : 05.344 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94670 , last: 94680 , vol: 1 , flags: 0 2016.06 . 09 17 : 07 : 05.344 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 63 , накопленный объем: 39 2016.06 . 09 17 : 07 : 05.344 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94670 , last: 94680 , vol: 1 , flags: 0 2016.06 . 09 17 : 07 : 05.344 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 64 , накопленный объем: 40 2016.06 . 09 17 : 07 : 05.460 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94670 , last: 94670 , vol: 1 , flags: 24 2016.06 . 09 17 : 07 : 05.460 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 65 , накопленный объем: 41 2016.06 . 09 17 : 07 : 05.516 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94670 , last: 94670 , vol: 1 , flags: 24 2016.06 . 09 17 : 07 : 05.516 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 68 , накопленный объем: 42 2016.06 . 09 17 : 07 : 05.516 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94670 , last: 94670 , vol: 1 , flags: 24 2016.06 . 09 17 : 07 : 05.516 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 69 , накопленный объем: 43 2016.06 . 09 17 : 07 : 06.016 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94670 , last: 94670 , vol: 1 , flags: 24 2016.06 . 09 17 : 07 : 06.016 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 70 , накопленный объем: 44 2016.06 . 09 17 : 07 : 06.557 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94670 , last: 94670 , vol: 1 , flags: 0 2016.06 . 09 17 : 07 : 06.557 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 71 , накопленный объем: 45 2016.06 . 09 17 : 07 : 06.702 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94660 , last: 94670 , vol: 2 , flags: 2 2016.06 . 09 17 : 07 : 06.702 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 73 , накопленный объем: 47 2016.06 . 09 17 : 07 : 06.702 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94680 , bid: 94660 , last: 94670 , vol: 2 , flags: 2 2016.06 . 09 17 : 07 : 06.702 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 73 , накопленный объем: 49 2016.06 . 09 17 : 07 : 06.718 test_ticks_openbroker (RTS- 6.16 ,M1) ask: 94670 , bid: 94660 , last: 94670 , vol: 2 , flags: 0 2016.06 . 09 17 : 07 : 06.718 test_ticks_openbroker (RTS- 6.16 ,M1) Реальный объем: 74 , накопленный объем: 51 など、インジケーターからの実際のボリュームは、累積されたボリュームよりもはるかに大きくなります。これにより、開発者にいくつかの質問が発生します。 1. OnCalculate()関数のvolume []配列から取得されたボリュームは、ティックから取得された累積ボリュームと同じである必要がありますか?もちろん、私の意見は、そうでなければ、なぜそれをダニで示すべきですか? 2. OnCalculate()関数を使用してボリュームを累積するのは正しいですか、それともOnBookEvent()を介してボリュームを取得する方が良いですか?ヘルプは言う:計算イベントは、Initイベントが送信された直後、および価格データが変更されたときにインジケーターに対してのみ生成されます。 OnCalculate関数によって処理されます。ですから、理論的には正しいのですが、コメントをお願いします。 3.テスト結果はフラグ分析なしで表示されます。フラグを分析する場合、私が理解している限り、フラグ24のティックからボリュームを取得する必要があります(最後とボリュームの同時変更): TICK_FLAG_LAST-ティックが最後の取引の価格を変更しましたTICK_FLAG_VOLUME-変更されたボリュームをチェックしますただし、この場合、累積ボリュームはさらに少なくなります。 (すべてのフィールドが記録されているので)ダニを正しく分析する方法についての開発者のコメントを聞きたいのですが、フラグは正しく実装されていますか?フラグ付きのティックに気づかなかったため、実装の正確性に関する質問が発生しました。 TICK_FLAG_BUY-買い取引の結果として発生したティックTICK_FLAG_SELL –売り取引の結果として発生したティックこれらのフラグの数はいくつですか?インジケータファイルもアプリケーションにあります。 ファイル: test_ticks_openbroker.mq5 3 kb 1...17181920212223242526 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
ティックインジケータのクエリから判断すると、time_mskフィールドのデータは1000の倍数である。つまり、ミリ秒の話ではなく、1秒の解像度の話です。
質問:では、MqlTickの構造を 拡張する意味は何だったのでしょうか?
あなたのところではそうではないのですか?
私はOpenbrokerのDemoと同じ場所にリアル口座を持っています。実際のすべてのAccessサーバーで同じ結果が得られますが、デモでも同じです。Si-6.16、RTS-6.16、SBRF-6.16を見ましたが、すべて1000の倍数になっています。
そうではありませんか?
現在、SymbolInfoTickクエリは、実際のミリ秒(1000の倍数)ではなく、MqlTick構造 体にゼロを返します。
次のビルドまでお待ちください。
PS on request CopyTicks ミリ秒をそのまま付与する。
このスレッドからこのインジケータをダウンロードしてテストしてみました。CopyTicksを介して過去30ティックを正確に取得します。あるいは、別のサーバー(openbrokerではない)で試してみるべきかもしれません。
>>"実際のミリ秒の代わりにゼロが与えられて いる"。
ゼロは出さず、常に1000の倍数の同じ数字を出す。(...2064, ...2064, ...3064, ..., ..., ..4064 )
このスレッドからこのインジケータをダウンロードしてテストしてみました。CopyTicksを介して過去30ティックを正確に取得します。あるいは、別のサーバー(openbrokerではない)で試してみるべきかもしれません。
>>"実際のミリ秒の代わりにゼロが与えられて いる"。
ゼロは出さず、常に1000の倍数の同じ数字を出す。(...2064, ...2064, ...3064, ..., ..., ..4064 )
ゼロはSymbolInfoTick関数で 渡されます。
CopyTicksでは、実際のミリ秒が指定されます。これが2064、3064、4064となれば、そうであったということになる。なぜそうなったのか、それはわからない。
あなたのコードに目を通しました。4dの出力指定は? time_mscが長いので、dだけではうまくいきません。I64dのはずです。
ゼロは、SymbolInfoTick関数で 与えられる。
CopyTicksでは、実際のミリ秒が指定されます。2064年、3064年、4064年なら、そうだったんですね。なぜそうなったのか、それはわからない。
あなたのコードに目を通しました。4dの出力指定は? time_mscが長いので、dだけではうまくいきません。I64dのはずです。
はい、すみません。コードは私のものではありません。このコードの作者は本当にStringFormatにスレがあるんですね。ループの各反復で Print (tick.time_msc) を通してプリントしました。その結果、最後にはすべてゼロになり、やはりミリ秒は得られない。CopyTicks リクエストは持続する。
ゼロは、SymbolInfoTick関数で 与えられる。
CopyTicksでは、実際のミリ秒が指定されます。2064年、3064年、4064年なら、そうだったんですね。なぜそうなったのか、それはわからない。
あなたのコードを見ました。出力指定子 %-4d とは何ですか? time_msc は長いので、d だけではうまくいきません。I64dのはずです。
最初の投稿からインジケータを変更 - StringFormatを弄らない、今はそのようになっているはずです。
はい、すみません。コードは私のものではありません。作者は本当にStringFormatにバグがあるんですね。ループの各反復で (tick.time_msc) を表示します。その結果、最後にはすべてゼロになり、やはりミリ秒は得られない。リクエストのCopyTicksはずっと行って います。
MetaQuotesのデモデータでのインジケーターはこちらです。
ティックにミリ秒がないことについては、ブローカーにお尋ねください。
MetaQuotesのデモデータでのインジケーターはこちらです。
ティックにミリ秒がないことについては、ブローカーにお尋ねください
ps my client build 1340
juriy5555 :
Пока не знаю, что и у кому конкретно писать, я в этом несколько месяцев. Буду надеяться, что ОпенБрокер всё таки обновит сервер.
ps мой билд клиента 1340
少し違う計画ですが、質問もありますし、ダニから伝わる情報が正しいのかと思います。
実際のボリュームについての質問。
インジケーターからティックに関する情報を要求すると、実際のボリュームはvolume[]配列に入れられます。また、理論的には、ティックから情報を取得する場合、キャンドルごとに累積されるボリュームは、volume[]配列の値と一致する必要があります。
テストコードの例を次に示します。
今のところフラグに執着せず、受信した各ティックがsVolの合計ボリュームを変更すると仮定します(ただし、私が知る限り、これは当てはまりません)。
新しいキャンドルの形成を待っており、ジャーナルのエントリを確認します。ブローカーオープニング、リアルアカウント、ビルド1340、RTS-6.16:
など、インジケーターからの実際のボリュームは、累積されたボリュームよりもはるかに大きくなります。これにより、開発者にいくつかの質問が発生します。
1. OnCalculate()関数のvolume []配列から取得されたボリュームは、ティックから取得された累積ボリュームと同じである必要がありますか?もちろん、私の意見は、そうでなければ、なぜそれをダニで示すべきですか?
2. OnCalculate()関数を使用してボリュームを累積するのは正しいですか、それともOnBookEvent()を介してボリュームを取得する方が良いですか?ヘルプは言う:
計算イベントは、Initイベントが送信された直後、および価格データが変更されたときにインジケーターに対してのみ生成されます。 OnCalculate関数によって処理されます。
ですから、理論的には正しいのですが、コメントをお願いします。
3.テスト結果はフラグ分析なしで表示されます。フラグを分析する場合、私が理解している限り、フラグ24のティックからボリュームを取得する必要があります(最後とボリュームの同時変更):
ただし、この場合、累積ボリュームはさらに少なくなります。 (すべてのフィールドが記録されているので)ダニを正しく分析する方法についての開発者のコメントを聞きたいのですが、フラグは正しく実装されていますか?フラグ付きのティックに気づかなかったため、実装の正確性に関する質問が発生しました。
インジケータファイルもアプリケーションにあります。