サービスデスクです。苦情、提案
この議論はフォーラムに持ち込もう」と言われたのです。
私の猪突猛進ぶりと、メモリークリーニングの問題、どちらをフォーラムで議論するつもりなのでしょうか？
この議論をフォーラムに持ち込もう」と言われたんですね。
私の無礼講とメモリークリーニングの問題、どちらをフォーラムで議論するつもりなのでしょうか？
そこで、フォーラムに議論をぶつけました。互換性を持たせよう。
無礼講ということで。Searcydeskに相談するのは、必ずしもいいことではありません。上記のような論調。
機能について機能が正常に動作していない根拠を示しました。あなたは私に「松葉杖」を差し出した。松葉杖がないと正しく作業できない場合は、将来的に疑問が生じないように、この松葉杖についての説明を文書に追加してください。
指標のデータについては、ずいぶん前に問題提起をしたのです
https://www.mql5.com/ru/forum/42180
問題が解決されたとのことで、安心しました。
発売1200の要旨にも書かれていた
17:ターミナル: MQL5プログラムから定期的にデータアクセスを行うにもかかわらず、履歴データを未使用としてアンロードしてしまうエラーを修正 しました。
では、問題は 解決していないのですか？
- www.mql5.com
指標のデータについては、ずいぶん前に問題提起をしたのです
https://www.mql5.com/ru/forum/42180
問題が解決されたとのことで、安心しました。
発売1200の要旨にも書かれていた
ターミナル：MQL5プログラムから定期的にデータにアクセスするにもかかわらず、履歴データを未使用としてアンロードしてしまう不具合を修正 しました。
では、問題は 解決していないのですか？
この場合のMT4という意味です。しかし、MT5については、この問題も関連しています。
この場合、私はMT4のことを指していました。しかし、MT5については、この質問も関連しています。
まだ1200にアップデートしていないので、直っているかどうか確認できない。
しかし、MT5にはそのようなバグがあった
まだ1200にアップグレードしていないので、直っているかどうか確認できません。
しかし、MT5にはそのようなバグがあった
今は1204をダウンロードしています。見てみよう。
- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索
こんにちは。今日もまた、サービスデスクは問題を聞こうとしないばかりか、聞こうともしない、という事実に遭遇しました。では、はじめましょう。
数日前、私はservicedeskに別の要望を書きました。依頼の骨子は以下の通りです（MT4の場合）。
Индикатор находится на ТФ, старше М1. Пытаюсь получить данные через функцию SeriesInfoInteger() с ТФ М1. Функция возвращает нули для свойств SERIES_BARS_COUNT, SERIES_FIRSTDATE, SERIES_SERVER_FIRSTDATE после того, как на М1 образовался новый бар. До того, как образовался новый бар - данные возвращаются корректные. После - нули.
2つ目の問題は、同じようなタイプのものです。TF MN1に表示されます。TF M5からSeriesInfoInteger()という関数でデータを受信しようとしています。しばらくは正しい値を返していたのですが、そのうち返さなくなり、0を返すようになりました。
どちらの場合も、データを取得しようとしているTFに戻り、より高いTFに切り替えた後、しばらくはデータが正しく表示されますが、その後-ゼロになります。
インジケーターはアプリケーションに搭載されています。
SeriesInfoInteger()関数の上記のプロパティで、インジケータ以外のTFの利用可能な履歴を確認/ロードする必要があります。
最初はデータがあり、次にデータがなく、取得できない、という曖昧な型はプログラマの誰も好まないだろう。しかも、そのプログラムが書かれたユーザーには嫌われる。メッセージから、このエラーをテストするためのプログラムを提供したことがお分かりいただけると思います。さらにログも提供されています。
データは単にドロップされ、データ要求のあったTFに変更することで、さらに取得することができる。
そして、SRからこんな返事が返ってきます。
ステータス：オープンクローズ
メッセージから、サービスデスク（またはその一部の従業員）は、ユーザーがエラーについて何を書こうがまったく気にしていないことがわかります。10秒に1回以上の頻度でデータへのアクセスを促される！？ログを見ると、データが要求される頻度がずっと高く、1ティックごとに要求されていることがわかります。このログも読まれていないのでしょうね。しかし、「もっと頻繁に」アクセスすることや、EAからデータにアクセスすることを提案されたことがあります。天才です。ああ、助けてもらったという感じで、すぐに応募は締め切られました。
移動するこれが私の答えです。
エラーは確認できましたか？
そして、サービスデスクの回答。
必要なチャートを開くと、そのデータは閉じるまで常にメモリ内に存在します。
ビルド900以降、積極的なメモリ解放を実装しています。メモリに問題がある場合、解放できるものはすべて解放されます。
十分なデータを持つ適切な最小のTFを選択するために、これらのプロパティが必要なのです。一方、私は、すべてのチャートを開くように提案されています。そして、同時にいくつの楽器を分析しても構わないので、可能な限りのチャートを開いて、満足してください。
アグレッシブなリリースと記憶障害について。端末のメモリに問題があるわけではありません。端末のログにエラーはありません。このことから、私は、メモリが解放されるかもしれない状況を知らされただけだと判断できます。でも、私の場合は明らかに違う。もう一つの事実は、サービスデスクが問題を調べようとせず、ただ排除しようとすることです。
次のページ
グラフに肉付けするよりも、アグレッシブなメモリ解放に磨きをかけたほうがいいと思いませんか？また、どのような記憶上の問題があるのでしょうか？そうだ、発売してくれ、でも松葉杖なしでさらに回収できるようにしてくれ！」と。
アプリケーションからインジケータを実行してみましたか？データは誰かのTFから、来る、来る、バンバン来る、もうやめてくれ！って理解してる？これは正常な動作なのでしょうか？
以下は、ドキュメントからの抜粋です。
Expert Advisorやカスタムインジケータの場合は、イベントベースの処理モデルを使用するのがよいでしょう。onTick()やOnCalculate()イベントで必要なデータが取得できない場合は、次にハンドラが呼ばれたときにデータが利用できることを期待して、イベントハンドラを終了させる必要があります。
引用した指標は、まさにこのモデルを使っています。データを受信していない場合は、次のティックにデータが到着することが期待されます。しかし、データが来なくなった！？そんなことないですよー。これは文書矛盾だ!
mql5では、すべてがあるべき姿で動作しているのに、なぜmql4では同じように整理することができないのですか？
そして、その答え。
いいえ、そんなことはありません。
もし、あるシンボル周期のデータが常に必要であれば、OnInitでそのデータが常に存在するようにすることです。例えば、単純な iTime(needed_symbol,needed_period) クエリの場合。そして、このiTimeを刻み続けること。
自分で端末にメモリを負担させているのですから。そこで、チャートのバーの数を必要な数だけ減らしてください。重要なデータをバックアップするには、適切なシンボル-ピリオドでチャートを開いてください。
現状に不満があれば、フォーラムで議論しましょう。ここで議論するのは無駄なことです。
MT5では、ヒストリカルデータの利用方法が全く異なるモデルです
順番に
いいえ、そうではなさそうです。
ただ、野暮ったいだけ。説明もコメントもない。
ドキュメントについて - ここでの結論は簡単です。もし、あるシンボル期間のデータが常に必要なら、このデータがOnInitで常に存在するようにします。例えば、単純な iTime(needed_symbol,needed_period) クエリの場合。そして、すべてのティックにiTimeをキープする。
最初の常識的な松葉杖 。ストレートな推論！？この結論はどこにあるんだ！？mqlに書き込んでいる全員が、この結論を自分で導き出したとでも思っているのでしょうか！？人のために憶病にならないこと。書かれている内容から結論が導き出される。比較のため。mql5のドキュメントでは、"Organization of access to data "のセクションで、データへのアクセスをどのように構成する必要があるかの例が示されています。すべて完璧に動作します。ここで、SeriesInfoInteger()関数が0を返した場合、必要なシンボル/期間のiTime()関数を呼び出す必要があることを推測する必要があります。なぜ、それが書かれていないのか？なぜ、このような松葉杖を使わずに、単純にSeriesInfoInteger()関数を改良できないのでしょうか？せめてドキュメントで明確にしてください。開発者の皆さん、質問を少なくしたいのであれば、一度ドキュメントにHowとWhatを詳細に書いてみてください。人は読める!
自分で端末にメモリを負担させているのですから。
何を伝えたかったんだろう！？端末はメモリを消費することができますが、端末にメモリを過剰に搭載することは、私にとって新しいことなのです。
そこで、チャートのバーの数を必要な数だけ減らしてください。重要なデータをバックアップするには、適切なシンボル-ピリオドでチャートを開いてください。
アプリケーションでインジケーターをテストしていたのは、何本目だと思いますか？聞いてもいないのに、気にしてないようですね。5000という数字です。それは、最低限のことです。そしてまた、チャートを開くという提案。了解です、ありがとうございました。ドキュメントに追加する（必要な場合）。
そしてファイナル。
現状に不満がある方は、この議論をフォーラムで行いましょう。ここで議論するのは無駄なことです。
MT5はヒストリカルデータの利用方法が全く異なるモデルです
そう、現状に満足していないのです。ユーザーは、あなたのプログラムのエラー（私はまだSeriesInfoInteger()関数の動作をエラーとみなしています）を見つけます。タダでやってくれるんです。しかも、直す気がないのではなく、話を聞いて、ユーザーから与えられたデータを見る気すらないのです。今に始まったことじゃないしな、事実が仇となって受け入れられているのに、エラーは気にしないのか。開発者の方々の声に耳を傾け、今後前向きな変化があることを期待します。あなたの今の態度は、あなたやあなたの製品に対する態度を非人道的にするものです。
皆さん、お読みいただきありがとうございました。
この機能を試したい人がいれば、インジケータは付録の中にあります。