Признак отрисовки ценового графика. Если установлено значение false, то отключается отрисовка любых атрибутов ценового графика и устраняются все отступы по краям графика: шкалы времени и цены, строка быстрой навигации, метки событий Календаря, значки сделок, тултипы индикаторов и баров, подокна индикаторов, гистограммы объёмов и т.д. Значение...
これはエラーではなく、チャートへのシンクコマンドのコストです
チャートから特性を取るのに、なぜチャートへのコマンドが必要なのでしょうか？メモリ内のすべてのチャートの特性表があり、そこからミリ秒ではなくナノ秒単位（マイクロ秒ですらない！）でデータを取り出せるだけではありませんか？
ChartSetInteger, ChartSetDouble, ChartSetString 関数が非同期であることは明らかです。
しかし、ChartGetInteger, ChartGetDouble, ChartGetString関数は 同期であるのに、なぜ実行速度の点で非同期として動作するのでしょうか？
もしそのようなテーブルがメモリ上に存在せず、これらの関数が要求されたパラメータを生成するために毎回チャートをスローダウンさせる必要があるとしたら、私は何も理解していません。
このような表を持ち、最新の状態を維持することは、決して高いことではありません。現実的には数キロバイトのメモリと、チャートの特性が変化したときにテーブルを更新するためのマイクロ秒のほんのわずかな時間。
イリヤス、教えてくれ、何が足りないんだ？
しかし、ChartGetInteger、ChartGetDouble、ChartGetString関数は同期であるのに、なぜ実行速度の点で非同期なのでしょうか？
非同期と同期という言葉について、何か間違った理解をしているようですね。
ある関数が非同期であると言うとき、それは現在の実行スレッドではなく、他のスレッドで実行されることを意味します - 並列です。
この関数は非同期式です。つまり、指定されたチャートに正常にキューイングされたコマンドの実行を待たず、直ちに制御を戻します。
このプロパティは、コマンドがチャートキューで処理された後にのみ変更されます。チ ャートキューのコマンドを即座に 実行するには、ChartRedraw関数を呼び 出す必要があります。
メインスレッドから ChartSetInteger 関数のように非同期で呼び出すと、実際の実行は別のスレッドで行われるため、高速に実行できます。
一方、ChartGetIntegerの同期関数を呼び出すと、スレッドの同期が必要となり、さらに時間がかかる場合があります。
この遅延は、並列スレッドがチャート構造データを常に更新している場合（例えば、ユーザーがチャートウィンドウを移動したり、履歴をスクロールしたりした場合）に特に顕著になります。
ほとんどの場合、シンプルさと信頼性のために、そのチャートデータ構造には1つの同期オブジェクトが使用されます。
データの細分化」で実行速度を向上させようとすると、今度はデッドロックが発生したり、データが更新されなかったり、より重要な部分で速度が低下することがあります。
一般的に、すでにスムーズに動いているものには手を出さないほうがいいと言われています。
非同期と同期という言葉を何か勘違いしているようですね。
ある関数が非同期であると言う場合、その関数は現在の実行スレッドではなく、他のスレッドで実行されることを意味します。
メインスレッドからChartSetIntegerのような非同期関数を呼び出すと、実際の実行は別のスレッドで行われるため高速に実行できます。
一方、ChartGetIntegerの同期関数を呼び出すと、スレッドの同期が必要となり、さらに時間がかかる場合があります。
この遅延は、並列スレッドがチャート構造体のデータを常に更新している場合（例えば、ユーザーがチャートウィンドウを移動したり、履歴をスクロールしたりした場合）に特に顕著になります。
ほとんどの場合、シンプルさと信頼性のために、そのチャートデータ構造には1つの同期オブジェクトが使用されます。
データの細分化」で実行速度を向上させようとすると、今度はデッドロックが発生したり、データが更新されなかったり、もっと重要なところで速度が低下したりすることがあるんです。
結局のところ、すでに安定して動いているものには手を出さないほうがいいんです。
おっしゃる通りですが、いくつかボトルネックがあるようです。マーケットは現在クローズしています。私は以下のコードを1つのチャートで実行しましたが、他は何も動きません。VPSで MT5だけ動かしていて、スクリーンショット以外ではチャート/MT5を操作していない。時間単位はμs、平均127μsですが、ピークは43,995μsです。
開発者の皆さん!
間違ったスレッドに書き込んでいたら訂正してください。使いやすさやデバッグのための提案もあり、多くの人に役立つと思いますし、私にとっても大切なことです。
1.オブジェクトのOBJPROP_TOOLTIPの 行の長さを長くする（2回で十分）。グラフィックを多用する戦略では、現在の長さはとても短いです。デバッグの場合は、必要なデータを収めるために毎回時間をかけなければなりません。そして、消費者向けの還元を定期的に変更したり追加したりする必要があります。
2.入力パラメータ名に対するコメントの長さを長くする（2回で十分）。入力パラメータに対するコメントは、消費者のために必要である。また、数が多い場合は、追加でナンバリングするのも便利です。最適化のためには、変数名を知ることが重要です。そのため、現在の長さではすべてを収めることができないことが多いのです。例
3.最適化結果テーブルのカラムの選択を多様化する -ENUM_STATISTICSから すべてのカラムを表示するところまでにして、ユーザーが必要なものを選択できる ようにする。これでは、解析がうまくいきません。ドローダウン（%）は、固定ボリュームでの最適化では意味がありません。通貨と預金額から最大ドローダウンを選択することはできません。最適化の際に買いポジションと売りポジションに強い偏りが出ることがありますが、それは一回テストをしてみて初めて分かることです。足りないパラメータを結果欄（STAT_CUSTOM_ONTESTER）に入力することが多いのです。しかし、そこに追加の結果基準を表示したいのですが、ENUM_STATISTICSから 標準基準の列数を変化させれば、1つしか表示できないので、まだ我慢できるのです。結局のところ、過剰な最適化と分析に多くの余分な時間を費やさなければならないのです。
ありがとうございました。
おっしゃる通りですが、いくつかネックがあるようです。現在マーケットはクローズしており、以下のコードを1つのチャートで実行しましたが、他は何も動きませんでした。VPSで MT5だけ動かしていて、スクリーンショット以外ではチャート/MT5を操作していない。タイミングはμsで、平均127μsだが、ピークは43,995μsである。
ピークがチャート・コメントのレンダリングであると仮定します。そうでなければ、チャート・キューが空のとき、ChartGetXXX関数呼び出し（同期を伴う呼び出しに注意）に0.13ミリ秒がかかります。
非同期と同期という言葉を何か勘違いしているようですね。
ある関数が非同期であると言う場合、その関数は現在の実行スレッドではなく、他のスレッドで実行されることを意味します。
メインスレッドから非同期のChartSetInteger関数を呼び出すと、実際の実行は別のスレッドで行われるため高速に実行できます。
一方、ChartGetIntegerの同期関数を呼び出すと、スレッドの同期が必要となり、さらに時間がかかる場合があります。
この遅延は、並列スレッドがチャート構造体のデータを常に更新している場合（例えば、ユーザーがチャートウィンドウを移動したり、履歴をスクロールしたりした場合）に特に顕著になります。
ほとんどの場合、シンプルさと信頼性のために、そのチャートデータ構造には1つの同期オブジェクトが使用されます。
データの細分化」で実行速度を向上させようとすると、今度はデッドロックが発生したり、データが更新されなかったり、より重要な部分で速度が低下することがあります。
一般的に、すでにスムーズに動いているものには手を出さない方がいいと言われています。
PrtScrボタンを押しながらチャートウィンドウを移動させると、最大5秒の恐ろしい遅延が発生します。
しかし、ALT + PrtScrでterminal.exeのプログラムウィンドウのスクリーンショットを撮るだけなら、全く遅延はありません。
内蔵のVPSサービスから 判断して、ある程度の実績がある。
ピークがチャートコメントのレンダリングであると仮定します。そうでなければ、チャートキューが空のとき、ChartGetXXX関数（注、同期をとった呼び出し）の呼び出しに0.13ミリ秒かかります。
いや、イリヤス、チャートコメントが ないようだ。過去ログを使って投稿してみる。
編集：以下はその結果です。実行後、ログのコピー以外、チャート、MT5、Windowsと何のやりとりもありません。チャート1枚のみで、他のソフトは起動していない。ピークは少ないですが、それでも平均に比べれば非常に重要です。(µs)
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Number = 7440
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Min = 37
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Max = 17776
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Avg = 147
いいえ、イリヤスさん、グラフについてはノーコメントの ようです。過去ログを利用して投稿します。
編集：これがその結果です。一度起動すれば、ログのコピー以外、チャート、MT5、Windowsと何のインタラクションもありません。チャート1枚のみで、他のソフトは起動していない。ピークは少ないですが、それでも平均に比べれば非常に重要です。(µs)
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Number = 7440
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Min = 37
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Max = 17776
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Avg = 147
アップデート:
最大ピークが本格的に向上しました。
2020.06.13 08：18：25.187 342152 (EURGBP, H1) Max = 23520
2020.06.13 08：18：25.187 342152 (EURGBP, H1) Min = 33
2020.06.13 08：18：25.187 342152 (EURGBP, H1) Max =81011
2020.06.13 08：18：25.187 342152 (EURGBP, H1) Avg = 149