2015.03.2720:24:56.568 (GAZR-6.15,M1) OnCalculate: Не скопированы тийминги по символу - GAZR-9.152015.03.2720:25:34.092 (VTBR-6.15,H1) OnCalculate: Не получены бары по символу - VTBR-9.152015.03.2720:25:34.100 (VTBR-6.15,H1) OnCalculate: Не получены бары по символу - VTBR-9.152015.03.2720:25:34.326 (VTBR-6.15,H1) OnCalculate: Не получены бары по символу - VTBR-9.152015.03.2720:25:34.326 (VTBR-6.15,H1) OnCalculate: Не получены бары по символу - VTBR-9.152015.03.2720:34:40.098 (SILV-6.15,H1) OnCalculate: Не получены бары по символу - SILV-9.152015.03.2720:34:40.126 (SILV-6.15,H1) OnCalculate: Не получены бары по символу - SILV-9.152015.03.2720:37:21.475 (RTS-9.15,H1) OnCalculate: Не получены бары по символу - RTS-12.152015.03.2720:37:21.491 (RTS-9.15,H1) OnCalculate: Не получены бары по символу - RTS-12.152015.03.2720:37:41.563 (RTS-9.15,H1) OnCalculate: Не получены бары по символу - RTS-12.152015.03.2720:40:41.051 (SILV-6.15,H1) OnCalculate: Не получены бары по символу - SILV-9.152015.03.2720:40:56.579 (RTS-9.15,H1) OnCalculate: Не получены бары по символу - RTS-12.152015.03.2720:40:56.595 (RTS-9.15,H1) OnCalculate: Не получены бары по символу - RTS-12.152015.03.2720:40:58.886 (VTBR-6.15,H1) OnCalculate: Не получены бары по символу - VTBR-9.152015.03.2720:40:58.896 (VTBR-6.15,H1) OnCalculate: Не получены бары по символу - VTBR-9.152015.03.2720:40:59.436 (SILV-6.15,H1) OnCalculate: Не получены бары по символу - SILV-9.152015.03.2720:41:00.892 (VTBR-6.15,H1) OnCalculate: Не получены бары по символу - VTBR-9.15
あなたは私たちの「読者」でもあるのですから...。質問です。
なぜ データが揃ったら 時系列を作るのか ( CopyTime(symbol,period,first_date+PeriodSeconds(period),1,times))。)?
彼らは準備ができていないのです。ディスクにあるのでしょう。サーバーの履歴と同期している可能性もあります(チャートが開いている場合、または他のプログラムが最近要求した場合)。
しかし、だからといって、機能がそのまま信じてくれるわけではありません。ディスクからデータを照会し、メモリにキャッシュを構築して、初めて「この日付から始まる履歴がある」と分かる。
しかし、この私の回答も、開発者からの度重なる回答も、動作するコードも、ドキュメントも、あなたの役には立ちません。関数が思ったように動かない、ここに障害がある。
選択的にではなく、もっと注意深くドキュメントを読んでください。ディスク上に履歴データがあっても、端末にとっては「間違いなくそこにある」とは限らない。この場合(インジケータからアクセスした場合)、関数はメモリ上の時系列キャッシュに対してのみ動作します。同期メモリアクセスが行われ、そこに準備された時系列がない場合は、(配列の最初の要素の)日付SERIES_FIRSTDATEは 返されないことを意味する。しかし、当然ながら、このリクエストによって、メモリへのタイムスケールのロードが準備される。
SERIES_TERMINAL_FIRSTDATE リクエストは、データベースの初期化およびサーバーとの同期に関連しているため、最初の呼び出しはいずれにしてもすぐには動作 しないでしょう。
原則として、SERIES_SERVER_FIRSTDATE を用いて必要な履歴を取得できることを確認する。もちろん、履歴要求のX回繰り返しをあてにすることもできますが、端末が SERIES_SERVER_FIRSTDATEで 履歴の存在を確認 すれば、時系列データの入手は時間の問題です(m1ベースとサーバーの同期、時系列の生成)。
それはわかったが、なぜ上記のようなやり方ではダメなのか教えてくれ。
情報処理速度に何ら影響を与えることはなかったはずだ。
楽器の情報があった場合 - それが最初に発生した日付を記録し、メモリに格納 - 8バイト!
保存しないこともできますが、SymbolSelect()をすると、メモリに入れることになります。
SeriesInfoInteger (SERIES_TERMINAL_FIRSTDATE) 関数でアドレス指定すると、次のようになります。
A -1 - データなし
Б.0 - データなし、ただし準備中
В.最初の情報提供日
そうすれば、すべてがクリアで透明なものになるはずです。
-1 - サーバーへ行く
0 - 時系列のチェックや構築を行うため、次のイテレーションまで待ちます。
> 0 ビルド時系列
あなたの言及から、私はあなたがそれをほとんどやったと理解しましたが、そうでないことが判明しました。
あるプログラマーが書き始め、別の人が書き終えたらしい
あなたの実装はFOREXには向いていますが、FORTSには非常に不都合です。
FORTSの場合、相場が長期間来ないこともあり、プラットフォームから時系列をダウンロードする。
というメッセージが表示され、サーバーにアクセスした状態でもう一度すべてのプロセスを 繰り返す必要があります。
あなたの実装はFOREXには向いていますが、FORTSには非常に不都合です。
FORTSでは、長い間相場が来ないこともあり、時系列はパイアチからアンロードされる
で、サーバーが ログインしている状態で、データを取得するプロセスをすべて もう一度繰り返す必要があります
ミカラスさん、私はまだあなたを信じていますよ。ここで語られたことは、必ずやすべて読み取ることができるだろう。
FORTS 助けてください。
マルチカレンシー・インディケーターは、それほど単純なものではありません。
まず、楽器の入手状況を確認します。
次に、ヒストリーが正常に読み込まれるように、使用するすべての楽器のチャートを開きます(不可視のチャートオブジェクトで十分です)。
そして、初めてCheckLoadHistoryで履歴を読み込んでみてください。
しかし、これも十分とは言えないかもしれません。
ついでに言うと、多通貨分析や指標の構築についても、この状況は好ましくないと思っています。どのように実装されるのか
タンバリンダンスですね。何かを計算し始める前に、何度も確認する必要がある...。他のプラットフォームでは見たことがありません。ユーザーの視点に立つと、そこではすべてがシンプルになるのです。
MT4のプログラミングを学んだ人でさえ、MT5のプログラミングの複雑さに怯えている人が多いのは周知の通りです。
もし私が開発者なら、私たちの生活をより快適にするために努力するでしょうね。のように、このタンバリンをすべて1つのコマンドにまとめます。
GatData(RTS,1000)
で、端末がこのタスクを解決し、必要に応じてチェックを行い、チャートを開き、履歴を交換し、更新する、などです。
そして、その実行後には、実際に使えるデータを手に入れることができます。
Z.I. 「主婦のための端末」という標語があったような......。
ミカラスさん、私はまだあなたを信じていますよ。ここで語られたことは、必ずやすべて読み取ることができるはずです。
こんぺいとう
(それ以上は悪しからず!)。
タムセリーの情報を得るための私のモデルのどこが悪いと思われましたか?
お前からじゃないから!?
開発者に "伝わる "ことで、みんなが 楽になるように
"人生 "と言っても、あなたのような賢い人が必ずいるはずです
だから、こうなるんだ!
ついでに言うと、多通貨分析や指標の構築についても、この状況は好ましくないと思っています。どのように実装されるのか
タンバリンダンスですね。何かを計算し始める前に、何度も確認する必要がある...。他のプラットフォームでは見たことがありません。ユーザーの視点に立つと、そこではすべてがシンプルになるのです。
MT4のプログラミングを学んだ人でさえ、MT5のプログラミングの複雑さに怯えている人が多いのは周知の通りです。
もし私が開発者なら、私たちの生活をより快適にするために努力するでしょうね。のように、このタンバリンをすべて1つのコマンドにまとめます。
GatData(RTS,1000)
で、端末がこのタスクを解決し、必要に応じてチェックを行い、チャートを開き、履歴を交換し、更新する、などです。
そして、その実行後には、実際に使えるデータを手に入れることができます。
主婦のための端末」というモットーを忘れずに...。
こんにちは。
普遍的で単純なアプローチでは、効率的なプログラムを書くことができなくなる。すべてのチェックを行うDyData関数を一つ作ることはできません。95%のケースでユーザーにとって不必要な、足手まといになってしまいます。
インジケーターの場合、そのチャートデータで可能な限り高速に動作します。そのために設計されています。どんな状況にも対応できる」ようにすると、単純なMAが複雑な怪物のように減速してしまいます。
決して開発者を擁護しているわけではありません。私も好きなものはたくさんありません。
しかし、私は建設的でありたいと思っていますし、端末の内部をすべて知っているわけではないことも理解しています。
ミカラスさんの言う通り、口ごもり(読まない)、「不愉快だ!」と叫び続けることで、議論が盛んになり、開発者の目に触れるようになる、という面もありますね。そして、彼らはそれについて何かをしてくれます(彼のチップのバグをすでにいくつか修正しています)。
ということで、たぶん無駄な愚痴です(笑)。
こんぺいとう
(それ以上は悪しからず!)
タムセリアルズで情報を得るための私のモデルのどこがBADだと思ったのでしょうか?
自分からじゃないから!!!?
開発者に "伝わる "ことで、みんなが 楽になるように
"人生 "と言っても、あなたのような賢い人が必ずいるはずです
だから、こうなるんだ!
もう手に入れました。
課題は、インジケーターを書く だけでした。そして、言語を改善しなければならないことが判明したのです。
こんなんだったら、アドバイスなんてしませんよ(笑)。
すでに持っています。
ただ、インジケーターを 書くというタスクが声高に叫ばれていたのです。しかし、言語の改良が必要であることが判明した。
そんなんだったら、アドバイスなんかしませんよ(笑)。
アンドレイ!
ここの書き込みの方がよっぽど時間をかけて書いていますね。
この間、「私の」主張(FORTS用)のインジケータを書くことができたはずです。
そして、その "松葉杖 "は、あなた自身が見たことがあるはずです。
アンドレイ!
ここに投稿している時間の方が長いのでは?
この間、「私の」泣き言に対するインジケータを書くことができたはずです(FORTS用)。
そして、私の言う「松葉杖」をご自分の目で確かめてください。
書いたからこそ、わかることがある。
言語の修正ではなく、インジケーターを取得することが目的であれば、今頃インジケーターも取得できていたはずです。
書いたことがあるからこそ、わかることがある。
言語の修正ではなく、インジケーターを取得することが目的であれば、今頃インジケーターも取得できているはずです。
インジケータを書いた のですが、使えません。
何をやってもうまくいかない。
OrderSendAsync() - ORDER_IDはあるが、トラッキングの仕組みはない。
グローバル変数があります。ターミナルを閉じるとリセットされるのですが...。
注文の実行には「理解できない」遅れがある - 半分はできていて、次は
チャラ男の告発...。
などなど・・・。
問題提起をするのは、問題やエラーが実際に存在するからです。
(作り話ではありませんよ!)
私はリアルマネーのためにビュローでトレードしているのであって、おふざけのためではない!」。
そしてそれが、私や取引するすべての人にとって、取引機能を記録するものなのです。
取引機能がFREQUENTであるARCHIVES。
MT5のアーキテクチャはSUPERで、とても気に入っていますが、すべてがきちんと動作し
データへのアクセスは迅速かつ容易であるべきです。
И...今日はこの辺で勘弁してください。