Mt4 サポート終了。 - ページ 40

新しいコメント
 
Реter Konow:
つまり、OOPの長所をゴミ箱に捨て続けて、みんなに荒らされ続けろってことですか（笑)でも、本質的にはあなたの言うとおりです。議論が間違った方向に行ってしまった。

でも、荒らしているわけではありません。荒らしに反応しなければいいだけ。

 

TWSでは、気配値の到着とは関係なく、時間によってバーが形成されます。相場がなく、新しいバーの 時間になると、最後の相場の価格の上にダッシュでバーが表示されます。この場合、すべての指標はMTと同じ方法で描画されます。バーに関する私の考え方は、すべてTSと仕事をした経験からきています。

MTでも同じなら、私のソリューションが最も効果的でしょう。ただし、それは...

したがって、私はもうこの製品を使うことをお勧めしません。

 
Alexey Viktorov:

ピーター 2回目ですが、別のテーマを提案します。何も書かなくていい、理論だけでいい。


ここで何を議論するのか。ポリモーフィズムの 最も純粋な形。OOPのルールです。
 
Alexey Viktorov:

でも、荒らしているわけではありません。荒らしは反応しないだけ。

また後日、あなたのトピックを紹介します。
 
Реter Konow:

なるほど、iBarsがリクエストされたときにバーが到着するのではなく、リクエストからしばらくして到着することもあるわけですね。そうすると、システムとしては寂しいことになります。そこがポイントです。


では、継続的にアクセスできるようにするためには？- 明らかにベストな解決策ではありません。

ただ、タスクが弱かった。しかし、誰かがそれを必要とする場合 - onTimerを連続的にポーリングすることなく、できるだけ早く別のシンボルの新しいバーを 受信するために、ユーザー割り込みも用意されています。
 
Nikolai Semko:
しかし、誰かがOnTimerをポーリングせずにできるだけ早く新しいバーを 取得する必要がある場合、カスタム割り込みがあります。

ここでバーのコンセプトさえ見直せば、すべてがうまくいくはずです。資源も節約できるし、解決策もシンプルになる。私 見ですが、バーは引用ではなく、時間に連動させるべきだと思います。

ですから、私のコードに間違いはありません。プラットフォームによってバーの概念に違いがあります。

 
Nikolai Semko:
そして、何を議論するのか？純粋な形でのポリモーフィズム。OOPのルールです。

知っている人には何の話題もない。ここでは、私がOOPについて少しでも学ぼうと決意した経緯の一例を紹介します。

新しいバーを定義する機能を例として取り上げたのは、無駄ではなかったと思います。この機能からすべてが始まったのです。現在のTFで新しいバーを定義する関数は、ずいぶん前に書かれたものです。突然、私も必要になったのですが、あるTFでそれを察知しました。まあ、問題ないでしょう。半クラで書き直しました。でも、いきなり今のTFにだけ必要なんです。なぜこの関数にPERIOD_CURRENTを渡さなければならないのでしょうか？ 問題ありません。もう一度書き直したら、今度は違う名前の2つの関数ができました。

何回書き直せばいいのか、どれに電話すればいいのか、思い出せない。そして、一つの名前で異なる入力パラメータを持つ関数を複数持つことができることを理解したとき、私の苦悩は終わった......。

 
Реter Konow:


私のコードに間違いがないことが判明しました。プラットフォームによって、バーの概念に違いがあるのです。

ピーターさん、申し訳ありませんが、あなたのコードはただのカオスです。
 
Nikolai Semko:

ちなみに、私のソリューションでは、配列を埋める 頻度を変えるだけで、1分間に1回休止する代わりに、1秒間に1回アクセスすれば、問題は完全に解決されます。この場合、システムの負荷が増えることはないと思われます。確認することができます。

if(Minute*Timer_frequency >= 60000)を if(Minute*Timer_frequency >= 1000)に置き換える。

 
Nikolai Semko:
申し訳ないが、ピョートル君のコードはカオスでしかない。
ニコライには悪いが、それは空言だ。プログラマーからそう言われるのは、ちょっと珍しいですね。
1...333435363738394041424344454647
新しいコメント