配列、バッファ及び時系列における索引付けの方向データアクセスの整理SeriesInfoIntegerBarsBarsCalculatedIndicatorCreateIndicatorParametersIndicatorReleaseCopyBufferCopyRatesCopyTimeCopyOpenCopyHighCopyLowCopyCloseCopyTickVolumeCopyRealVolumeCopySpreadCopyTicksCopyTicksRangeiBarsiBarShiftiCloseiHighiHighestiLowiLowestiOpeniTimeiTickVolumeiRealVolumeiVolumeiSpreadデータアクセスの整理このセクションでは、価格データ(時系列)の取得、格納、及びリクエストに関する質問が考慮されます。端末で使用可能になる前に受信されて処理されなければなりません。取引サーバへの接続が必要です。データは、端末のリクエストに応じてサーバから分足のパックブロックの形式で受信されます。言語のプログラムで送られたかなどの方法には依存しません。中間形式で格納されます。別々のフォルダに書き入れられます。拡張子を持つファイルに書き込まれます。各ファイルは一年分の分足を格納します。これらのファイルは全ての時間軸の価格データを準備するために使用され、直接アクセスは意図されていません。形式で構築するためのデータ元として使用されます。形式のデータは最大限に迅速なアクセスのために用意された時系列です。プログラムチャートのリクエストに応じて作成されます。データ量は「チャートでのバーの最大数」パラメータの値を超えてはいけません。拡張子を持つファイルに格納されます。格納されて保存されます。解放されてファイルに保存されます。データは、他の時間軸かの準備ができたデータがあるかどうかにかかわらず各時間軸で用意されます。データ形成及びアクセスのルールは全ての時間軸で同じです。しての可用性があるわけではありません。形式での自動更新が呼び出されます。それらのデータを計算の入力データとして暗黙的に使用する指標全ての再計算につながります。形式のバーの数を制限します。これは全ての利用可能な時間軸のために有効であり、コンピュータリソースを節約するために提供されています。ビットアプリケーション).に達することがあるので注意が必要です。「チャートのバーの最大数」の変更はクライアント端末の再起動の際に有効になります。このパラメータの変更は、サーバでの追加データの自動や時系列の追加のバーの形成にはつながりません。プログラムによってリクエストされた場合は、追加の価格データがサーバからリクエストされ、時系列は新しい制限をもって更新されます。サーバから要求されたデータの量は「チャートのバーの最大数」パラメータを考慮した上のこの時間軸のバーの必要な数に相当します。このパラメータで設定された制限は厳密ではなく、時間軸で利用可能なバーの数が現在のパラメータ値を少し上回る場合があります。形式での使用が準備中のデータの可用性は、これらのデータの絶対的な可用性を意味するものではありません。プログラムから価格データや指標値にアクセスする場合、それらの特定の瞬間、また特定の開始時間での可用性が保証されていないことを忘れてはなりません。格納されず、端末データベースへの直接アクセスのみが与えられているという事実と関係しています。形式の共通のデータから構築され、サーバからのデータの更新は、全ての時間軸データの更新及び指標の再計算ににつながります。そのために、データは少し前に利用可能であったとしても利用不可能になることがあります。プログラムは任意のシンボルと時間軸のデータを呼び出すことが出来るので、必要な時系列のデータが端末にまだ形成されていないまたは必要な価格データが取引サーバと同期されていない可能性があります。この場合、待ち時間を予測するのは難しいです。「無演算」ループを使用したアルゴリズムは最善の解決策ではありません。スクリプトは、イベント処理を持たないため代替アルゴリズムの選択肢がないので、唯一の例外です。カスタム指標では、このようなアルゴリズムや他の「無演算」ループは、全ての指標の計算と他のシンボルの価格データの処理の終了につながるため、推奨出来ません。エキスパートアドバイザーと指標ではハンドルのイベントモデルが使用されるべきです。イベントの取り扱い中に必要な時系列のデータの受信に失敗した場合、ハンドラの次の呼び出しの間にアクセスの可用性に依存してイベントハンドラを終了する必要があります。選択されたシンボルの履歴を取引サーバから受信するためのリクエストを実行するスクリプトの例を考えてみましょう。このスクリプトは、選択したシンボルのチャートで実行するためのものです。1分間のデータとして受信され、事前定義された時系列はそれから構築されるので、時間軸は重要ではありません。価格履歴の始まりを示す開始日の3つの入力パラメータを必要とします。不足している履歴をリクエストする前に、関数コードに必要なチェックを挿入します。第一に、銘柄名と期間値が正しいことの確認が必要です。ウィンドウで利用可能であることを確認します。return(-1);SymbolSelect(symbol,true);}示された銘柄/期間のペアで利用可能な履歴の開始日を受信する必要があります。入力パラメータの値が利用可能な履歴の範囲内にあるなら、その後取引サーバリクエストは必要ありません。修飾子が使用されます。return(1);次の重要なチェックは、関数が呼び出されるプログラムの種類のチェックです。指標と同じ期間を持つ時系列の更新リクエストを送信することは望ましくありません。指標と同じシンボル期間のデータのリクエストが望ましくないのは、履歴データの更新が指標が作動するのと同じスレッドで実行されるという事実があるからです。従ってデッドロックが発生する可能性が高いです。回取引サーバにリクエストを送らないですむか見てみます。形式でのデータが使用可能な初めの日を見つけます。パラメータ値と比べます。関数の本体に残っている場合、取引サーバから欠落している価格データをリクエストする必要があります。関数を使用して「チャートでのバーの最大数」値を返します。max_bars=TerminalInfoInteger(TERMINAL_MAXBARS);これは、余分なデータのリクエストを防止するのに必要です。修飾子を使用して見つけます。変数が値を受け取るまでの遅延の5ミリ秒の小さい枠で呼び出されます。取引サーバからの価格データリクエストを開始する日付けの正しい値を示してみましょう。早い場合、対応するエントリーが操作ログに出力されます。欠落した価格データを取引サーバからリクエストする準備ができました。ループ形式でリクエストを作成し本体に記入を開始します。して再構築された時系列と中間の履歴との間の同期を待ちます。この時間軸での現在のバーの数を受け取ります。多い場合、終了します。早い場合、作業が終わったので終了します。サーバから新しい期間の履歴をリクエストします。点は、すでに知られている手段によって実施されます。サーバから新しい期間の履歴をリクエストします。番目のポイントが残っています。履歴のリクエストです。サーバに直接参照することは出来ません。自動的にサーバリクエストの送信を開始します。関数の使用が一番容易です。パラメータ(価格データコピーの開始点からのバーの数)は端末で利用可能な履歴の範囲からとられなければなりません。足を複製する試みは無意味です。このような要求は誤ったものとして理解されて処理されず、追加の履歴は取引サーバから読み込まれません。足を複製する理由です。これは、欠落している履歴の取引サーバからのスムーズな読み込みを提供します。大きい数の足が読み込まれます。copied=CopyTime(symbol,period,bars,100,times);コピー操作の後では、複製された要素の数が分析されるべきです。試行失敗の後、関数の動作が停止されます。複製された値のほうが小さい。バーの数がチャートに描画出来るより多い。関数の呼び出し後に処理出来る追加情報を取得するための終了コードも戻されます。undefined");}この関数の完全なコードは、リクエスト結果の取り扱いを持つ任意のデータへのアクセスの正しい構成を示すスクリプトの例に記載されています。