2. Возвращает true или false в зависимости от успешности выполнения функции.
В случае успеха значение свойства помещается в приемную переменную,
передаваемую по ссылке последним параметром.
bool ChartGetInteger(
long chart_id, // идентификатор графикаint prop_id, // идентификатор свойстваint sub_window, // номер подокнаlong& long_var // сюда примем значение свойства
);
通信が途絶えることもなく、ティックの引きすぎもなく、大きなTFほどレアなのです。
そして、開始日から終了日までの計算方法（3つあることがわかった）なし
おそらくそうなる（すべてのバーを再計算する）のでしょうが、まだ正確ではないので、確認方法がわかりません。
とはいえ、あくまで思いつきなので、確認してみましょう。
もしかしたら、それを避けるための別のアプローチがあるのかもしれませんが...。
イェデルキン
もちろん、アプローチもあります。If(prev_calculated==0),全ての バーについて初期計算を行う。その後、新しいティックごとに（0 < prev_calculated < rates_total の場合）、最後に現れたバーに対してのみ for(int i=prev_calculated-1;i<rates_total;i++) のような計算を実行します。まだ再描画しています。このように実装されています。
int calculated1=BarsCalculated(StdDev1Handle)。
if(CopyBuffer(StdDev1Handle,0,0,to_copy,ExtStdDev1Buffer)<to_copy)を返す(0)。
int data1=CopyOpen(Symbol1,0,0,rates_total,Open1Buffer)とする。
for(int i=rates_total-2; i>=0; i--){
if(time[i]>=DateStart)です。
{
再描画された後、再描画されないが、多分、コードの作業の正しさについてであろう
が、端末にはない（でも、少なくとも今はそれほど特徴的ではない...）。
ティックがあってもなくても再描画される場合があります。
コヒーレンシー（因果関係）がない印象です。
プロセッサの弱さかハングアップしか思い浮かばない
思い当たるのは、プロセッサが弱いか、端末がフリーズしている（MT5）ことくらいでしょうか。
alexluek:
再描画されたりされなかったり、でもそれはコードの正しさに関わることです。
と端末に表示されない（でも、少なくとも今はそれほど特徴的ではない...）。
ChartGetInteger 関数の2番目のバージョンで作業された方はいらっしゃいますか？
?受信側の変数にプロパティの値が渡されていないようです。少なくとも、この挙動は、コンストラクト
この関数は真を返しますが、変数windowsにはこの変数の初期化時に得られた値が格納されます。この場合、関数の最初のバージョンは正しい値を出力します。(さらにもう一つ些細なことですが、取得する変数がlong型で 宣言されている場合、コンパイラは警告を発生させます)。ChartGetInteger 関数の2番目のバージョンで作業された方はいらっしゃいますか？
?受信側の変数にプロパティの値が渡されていないようです。少なくとも、この挙動は、コンストラクト
この関数は真を返しますが、変数windowsにはこの変数の初期化時に得られた値が格納されます。この場合、関数の最初のバージョンは正しい値を出力します。(さらにもう一つ些細なことですが、取得する変数がlong型で 宣言されている場合、コンパイラは警告を発生させます)。そう、そういうものがあるんです。唯一、背景色をお願いしてみました。servicedeskに手紙を 書こうと思っていたのですが、忘れてしまいました。
ChartGetInteger 関数の2番目のバージョンで作業された方はいらっしゃいますか？
?受信側の変数にプロパティの値が渡されていないようです。少なくとも、この動作は、コンストラクト
この関数は真を返しますが、受信側のウィンドウズ変数には、この変数の初期化時に取得した値が格納されます。この場合、関数の最初のバージョンは正しい値を出力します。(もう一つ小さなことですが、受け取り側の変数がlong 型で宣言されている場合、コンパイラは警告を発生させます）。間違った機能を使用しているようです。これは関数の最初のバリエーションです（3つのパラメータを持つ）。これは（あなたが考えているように）真を返さないが、パラメータの値
あなたのコードは見ていませんが、正しいようです。
機能の使い方を間違えているようです。これは、関数の最初のバージョンです（3つのパラメータを持つ）。これは（あなたが考えているように）真を返さないが、パラメータの値
あなたのコードは見ていませんが、正しいようです。
機能の使い方を間違えているようです。これは、関数の最初のバージョンです（3つのパラメータを持つ）。これは（あなたが考えているように）真を返さないが、パラメータの値
OKです。調べてみよう。
1.関数が「あれ」使われているのは、例と同じ名前の関数を引用しているからです。その関数のどちらのバージョン（第1、第2）を使っているかという問題でしかないでしょう。
2.実際、形式的には、最初の関数は3つのパラメータを持ち、2番目の関数は4つのパラメータを持つ。しかし、両方の呼び方のバリエーションに存在するsub_window パラメータの説明には、「ほとんどのプロパティはサブウィンドウ番号を必要としない」と明記されています。CHART_WINDOWS_TOTAL (インジケータ・サブウィンドウを含むチャート・ウィンドウの総数) のようなプロパティにウィンドウ番号を表示する必要があるのかないのか、疑問が生じます。
3 ウィンドウ/サブウィンドウの合計数を得るために、チャートのウィンドウ/サブウィンドウの数を個別に指定する必要はないと考えるのが自然です。この結論は、Handbook自体に直接記載されている例（Charts Propertiesの 項）によって裏付けられています。
同様の方法は、「チャート操作／ChartWindowOnDropped」セクションで説明しています。
これらの例から、チャートのウィンドウ/サブウィンドウの総数を求めるのに、サブウィンドウの番号を個別に指定する必要はないというのが、Handbookの作者の立場であることがわかります。もちろん、この例では関数の最初のバリアントを使用していますが、同じプロパティ（つまり、CHART_WINDOWS_TOTAL）について話しているので、関数の2番目のバリアントでも同じ結論が成り立つと考えるのが自然でしょう。特に、ハンドブックには、関数の2番目のバリエーションにゼロのサブウィンドウ番号を指定する必要性について、何の留保もないことを考慮すれば、なおさらであろう。
4.あなたの例では、プロパティ自体がサブウィンドウ番号を指定する必要がない場合でも、第3パラメータ（sub_window）は常に関数の第2バリアントで指定する必要があることを示唆しています。つまり、最初の関数の変形（2つのパラメータと3つのパラメータの両方で使用可能）とは異なり、2番目の関数の変形は常に 4つのパラメータすべてを必要とします。そうだろ？
5.もし正しければ、2つのことが証明されたことになります。まず、私が最初に考えた問題が間違っていることが判明しました。第二に、この誤植の原因は、『ハンドブック』の情報が不完全であることです。そこで、ハンドブックに「2番目のオプションにはデフォルト値がないため、サブウィンドウの番号は常に指定する必要がある」という説明を加えることを提案します。サブウィンドウ番号を必要としないほとんどのプロパティでは、「0（メインチャートウィンドウ）」を指定することが必要です。とか、そんな感じです。
例を挙げていただきありがとうございます。短くて要領がいいんです。
最初の関数では intsub_window=0 は デフォルト値なので省略できるが、2番目の関数ではそのようなデフォルト値はないので、指定 する必要がある。
OKです。整理してみよう。
1.例題と同じ名前の関数を引用しているので、使用される関数は「that」です。その関数のどちらのバージョン（第1、第2）を使っているかという問題でしかないでしょう。
2.実際、形式的には、最初の関数は3つのパラメータを持ち、2番目の関数は4つのパラメータを持つ。しかし、両方の呼び方のバリエーションに存在するsub_window パラメータの説明には、「ほとんどのプロパティはサブウィンドウ番号を必要としない」と明記されています。CHART_WINDOWS_TOTAL (インジケータ・サブウィンドウを含むチャート・ウィンドウの総数) のようなプロパティにウィンドウ番号を表示する必要があるのかないのか、疑問が生じます。
3 ウィンドウ/サブウィンドウの合計数を得るために、チャートのウィンドウ/サブウィンドウの数を個別に指定する必要はないと考えるのが自然です。この結論は、リファレンスマニュアル（セクション「チャートのプロパティ」）に直接記載されている例によって裏付けられている。
1.この関数が実際にオーバーロードされていることを考慮すると、そうではないと主張することができます（ご想像の通り、議論の余地はありますが）。
2.そこがポイントです。MQL5の関数オーバーロードのロジックを正しく理解すれば、最初のオプションは2または3のパラメータで使用でき、2番目のオプションは4つのパラメータでのみ使用できます。
つまり、関数が2つまたは3つのパラメータを受け取った場合、MQL5は最初のオプションを使用し、4つのパラメータを受け取った場合は常に2番目のオプションを使用するのです。
ポイントは、パラメータ番号が4でない2番目の変形を使用すると、コンパイラはその呼び出しで混乱することです。
3.リファレンスにちょっとした不正確な表現があります（というか、ちょっと間違った表現）。一般的な意味は以下のとおりです。ほとんどのプロパティはウィンドウ番号を必要と せず、そのようなプロパティの 最初のオプションでは、ウィンドウ番号を省略することができます（2番目のオプションでは、指定する必要がありますが、無視されます）。
4.以上から、この例ではコンパイラは関数の最初の変形を選択することになります。
コンパイラは、最初の変形では3番目のパラメータを省略できるが、2番目の変形では必ず存在しなければならないという理由で、このような結論を下すのです!!!!