[SERVICE DESK】タイマーでシニアTFの時刻を取得する際にエラーが発生！？ - ページ 14 1...78910111213141516 新しいコメント Konstantin Nikitin 2018.10.06 14:16 #131 今まで何度か走らせていますが。面白いけど、いつもうまくいくとは限らない。接続が間に合わないこともある。 自分には良い縁があるんだ。それが理由かもしれません。 Konstantin Nikitin 2018.10.06 14:23 #132 しかし、このテストで気づいたのは、そういうことではありません。パスカウントで今動作させても、OnCalculateで 10回パスが出るんですよ、 今でも。結局、インジケータ起動時に少し遅延させるのが一番よさそうです。 削除済み 2018.10.06 14:26 #133 Konstantin Nikitin: しかし、今回のテストでは、何か違うことに気づきました。今パスカウントで実行しても、OnCalculateで 10回パスが出ます。その結果、インジケーター開始時の遅延を小さくすることがベストな選択と思われます。松葉づえによる解決は必要ない、繰り返す。今の挙動は私に合わない、開発者自身のアドバイスも通用しない。このようなことは、放っておいても何もいいことはないのです。問題が検出されたので、開発者が解決する必要がある。 Konstantin Nikitin 2018.10.06 14:32 #134 Alexey Kozitsyn:松葉づえによる解決は必要ない、繰り返す。今の挙動は私に合わない、開発者自身のアドバイスも通用しない。このようなことは、放っておいても何もいいことはないのです。問題が発見されたら、開発者が解決しなければならない。私が見たものを説明しました。どうすれば解決できるかを考えなければならない。つまり、ファーストパストラッキングなど、全く意味がないのです...。 削除済み 2018.10.06 14:39 #135 Konstantin Nikitin:私が見てきたものを説明しました。どう対処するか考えなければならない。つまり、ファーストパストラッキングなど、どう考えてもまずい。そういう「薄い」ところでテストして、エラー番号で正しく動作する仕組み（リクエストごとにノックして）とか、履歴アクセス機能で何らかの追加チェック（つまり何時間もそういう問題を探さないように内蔵）とかが必要だと思うのですが、どうでしょう？そして、この仕組みはドキュメントで詳しく説明されるべきです。そうすれば、開発者に質問されることもないでしょう。でも、今はどうなんでしょう？ドキュメントには、古いTFのデータへのアクセスについて何も書かれていないので、開発者自身がデータの入手方法を知らないのです。ヒゲ年のフォーラムには、同じような理由のリンクがいくつかあるだけです。 Konstantin Nikitin 2018.10.06 15:19 #136 サーバーとの違いが時間単位でわかるなら。現在のローカルクロックと最後のアワーバーの開始時刻 の比較を使用することができます。TimeCurrent は、時刻が更新されない可能性があるため、適切ではない。 こんな感じ MqlDateTime mqlDateTime; TimeToStruct( (TimeLocal()-60*3), mqlDateTime ); mqlDateTime.min = 0; mqlDateTime.sec = 0; if( IsConnected() ) Comment( TimeToString( iTime(Symbol(), PERIOD_H1, 0) ), "\n", TimeToString( StructToTime(mqlDateTime) ) ); Taras Slobodyanik 2018.10.06 16:11 #137 Alexey Kozitsyn:ところで、端末版についての質問に答えていないね。端末1121、1090 アレクセイ・コジツィンサーバーとの通信が確立される。上級TFデータ要求時、データの準備が出来ていない場合、エラーまたは0を返す。データが準備できた場合 - 実際のデータのみを返す。それだけです。データが長時間準備できない場合、エラーまたは0を返すようにする。 ここに誤りはない。接続と履歴データがあります。 すでに端末に入っているデータはすぐに表示されます。 新しいデータは、ブローカーにリクエストを送り、何か足りないものがあればアップロードする必要があるため、遅延が発生する。 新しいデータが表示されると、すぐにティックが生成されます（マーケットが閉じている現在でも）。新しいバーの update-appearanceをチェックして、自分で変数を変更すればいいのです。 ps. mt4にはデータの関連性を示すフラグがありません。 削除済み 2018.10.06 17:31 #138 Taras Slobodyanik:端末1121、1090 ここに誤りはない。接続があり、履歴データが存在する。 すでに端末にあるデータはすぐに表示されます。 新しいデータが届くと、ブローカーにリクエストを送り、何か足りないものがあればアップロードする必要があるため、遅延が発生する。 新しいデータが表示されると、すぐにティックが生成されます（マーケットが閉じている現在でも）。新しいバーの update-appearanceをチェックして、自分で変数を変更すればいいのです。 ps. mt4にはデータ更新フラグがありません。やはり、アップデートした端末で再度試してみる必要がありそうです。 コントロールできない行動には、断固として反対です。この関数はエラーにならずに不正なデータを返しますが、これは間違いです。あなた自身も後でそのような場面に遭遇し、「何が問題なのだろう」と思うことでしょう。 例えば、最初は関数がエラーを返したとする。発売される。次のクエリで、この関数はエラーを返さず、いくつかの「正しくない」データを返しました。大丈夫なんですか？ Taras Slobodyanik 2018.10.06 20:04 #139 不正確なデータとはどういう意味ですか？ それがない、あるいは接続されていない、などという場合は、はい、エラーになります。 そして、数えるほどしかないのです。 すべてのデータが正しい場合 - すべてがうまくいき、すべてが実行されます。 インジケーターがデータ更新に追従していない。 ブローカーから新しいバーが来て、それをチェックすることはない。 確認するとすべて正しいことがわかるように、2行ほど追加しました。 新しいバーを確認するのは作業状況です。 削除済み 2018.10.07 09:07 #140 Taras Slobodyanik:不正確なデータとはどういう意味ですか？そして、私の一番最初の投稿を見てください。そこにエラー4066が表示されていませんか？そして、エラー0となり、不正なデータが返されます。なぜ、データを送信する前に関数（この場合は SeriesInfoInteger()）が関連性をチェックしないのでしょうか？なぜエラーフラグが立たないのでしょうか？ほら、後でエラーを探すより、内部チェックが通るのを少し待った方がいいでしょ。 しかし、その後もいろいろとアドバイスをいただきましたが、まだ結果は出ていません。しかも、それはタイマーがどうのこうのという話ではないことがわかったのです。 1...78910111213141516 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
自分には良い縁があるんだ。それが理由かもしれません。
しかし、今回のテストでは、何か違うことに気づきました。今パスカウントで実行しても、OnCalculateで 10回パスが出ます。その結果、インジケーター開始時の遅延を小さくすることがベストな選択と思われます。
松葉づえによる解決は必要ない、繰り返す。今の挙動は私に合わない、開発者自身のアドバイスも通用しない。このようなことは、放っておいても何もいいことはないのです。問題が検出されたので、開発者が解決する必要がある。
松葉づえによる解決は必要ない、繰り返す。今の挙動は私に合わない、開発者自身のアドバイスも通用しない。このようなことは、放っておいても何もいいことはないのです。問題が発見されたら、開発者が解決しなければならない。
私が見たものを説明しました。どうすれば解決できるかを考えなければならない。つまり、ファーストパストラッキングなど、全く意味がないのです...。
私が見てきたものを説明しました。どう対処するか考えなければならない。つまり、ファーストパストラッキングなど、どう考えてもまずい。
そういう「薄い」ところでテストして、エラー番号で正しく動作する仕組み（リクエストごとにノックして）とか、履歴アクセス機能で何らかの追加チェック（つまり何時間もそういう問題を探さないように内蔵）とかが必要だと思うのですが、どうでしょう？そして、この仕組みはドキュメントで詳しく説明されるべきです。そうすれば、開発者に質問されることもないでしょう。でも、今はどうなんでしょう？ドキュメントには、古いTFのデータへのアクセスについて何も書かれていないので、開発者自身がデータの入手方法を知らないのです。ヒゲ年のフォーラムには、同じような理由のリンクがいくつかあるだけです。
こんな感じ
ところで、端末版についての質問に答えていないね。
端末1121、1090
サーバーとの通信が確立される。上級TFデータ要求時、データの準備が出来ていない場合、エラーまたは0を返す。データが準備できた場合 - 実際のデータのみを返す。それだけです。データが長時間準備できない場合、エラーまたは0を返すようにする。
ここに誤りはない。接続と履歴データがあります。
すでに端末に入っているデータはすぐに表示されます。
新しいデータは、ブローカーにリクエストを送り、何か足りないものがあればアップロードする必要があるため、遅延が発生する。
新しいデータが表示されると、すぐにティックが生成されます（マーケットが閉じている現在でも）。
新しいバーの update-appearanceをチェックして、自分で変数を変更すればいいのです。
ps. mt4にはデータの関連性を示すフラグがありません。
端末1121、1090
ここに誤りはない。接続があり、履歴データが存在する。
すでに端末にあるデータはすぐに表示されます。
新しいデータが届くと、ブローカーにリクエストを送り、何か足りないものがあればアップロードする必要があるため、遅延が発生する。
新しいデータが表示されると、すぐにティックが生成されます（マーケットが閉じている現在でも）。
新しいバーの update-appearanceをチェックして、自分で変数を変更すればいいのです。
ps. mt4にはデータ更新フラグがありません。
やはり、アップデートした端末で再度試してみる必要がありそうです。
コントロールできない行動には、断固として反対です。この関数はエラーにならずに不正なデータを返しますが、これは間違いです。あなた自身も後でそのような場面に遭遇し、「何が問題なのだろう」と思うことでしょう。
例えば、最初は関数がエラーを返したとする。発売される。次のクエリで、この関数はエラーを返さず、いくつかの「正しくない」データを返しました。大丈夫なんですか？
不正確なデータとはどういう意味ですか？
それがない、あるいは接続されていない、などという場合は、はい、エラーになります。
そして、数えるほどしかないのです。
すべてのデータが正しい場合 - すべてがうまくいき、すべてが実行されます。
インジケーターがデータ更新に追従していない。
ブローカーから新しいバーが来て、それをチェックすることはない。
確認するとすべて正しいことがわかるように、2行ほど追加しました。
新しいバーを確認するのは作業状況です。
不正確なデータとはどういう意味ですか？
そして、私の一番最初の投稿を見てください。そこにエラー4066が表示されていませんか？そして、エラー0となり、不正なデータが返されます。なぜ、データを送信する前に関数（この場合は SeriesInfoInteger()）が関連性をチェックしないのでしょうか？なぜエラーフラグが立たないのでしょうか？ほら、後でエラーを探すより、内部チェックが通るのを少し待った方がいいでしょ。
しかし、その後もいろいろとアドバイスをいただきましたが、まだ結果は出ていません。しかも、それはタイマーがどうのこうのという話ではないことがわかったのです。