エラー、バグ、質問 - ページ 1494

 
zaskok3:

また、OnMarketwatchがないことについての説明もお願いしたい。

なぜこのイベントがMTにないのか、説明を求めないほうがいい。

サービスデスクに、どのように機能するべきだと考えているのか、なぜ99%のトレーダーがそれを必要としているのかを詳しく説明する必要があります。

 
Maxim Khrolenko:
私見ですが、ここでOnTimer()を使って、Xミリ秒ごとにイベントを呼び出すことができます。
このソリューションは、長い間、より正確なバリアントで来ている - 必要なシンボルに指標を置くとExpert Advisorにユーザーイベントを 送信します。
 
zaskok3:
Marketwatchに新しいティック到着イベントを追加しました。OnTickと似ていますが、1つのシンボルではなく、マーケットウォッチに登録されているすべてのシンボルの新しいティックに反応するのが唯一の特徴です。

現在の見積もりフローでは、別のOnTickを処理する間に、自分のティックが一括で到着することもあります。

なぜか、あるイベントが発生すると、同じExpert Advisorで別のイベントが処理されていても(つまり並行して)、そのイベントのハンドラが即座に起動されると考える人が多いようです。ということはありません。

すべてのイベントは、同じExpert Advisorの1つの一般的なキューに並んでいます。Expert Advisor はそれらを一つずつ処理します。そして、あるイベントの処理をいかに効果的に実装するかは、すべてプログラマー次第なのです。しかし、プログラマーがスーパープログラマーでスーパーカーを持っていても、イベントが多ければ(外国人キャラクターからのテロップがあればなおさら)キューが膨らんでしまう。

他人のキャラクターからダニを欲しがる論拠は何でしょうか?"配信に間に合わないかもしれないから、正しいキャラクターを把握するためにタイマーを回したくない"。また、他人のシンボルのティックイベント(特に複数のシンボルを監視している場合)は、別のイベントの独自の処理によってキューで遅れることがあるので、景品に遅れる確率が非常に高くなります。

信じてください、私たちは実際に他人のダニについてのイベントを議論してきました。だから、「タイマーを使ったほうがよっぽどいい」という結論に至ったのです。

 
zaskok3:

MQL4+では、入力パラメータをプログラムで 変更する必要がある場合、externは欠かせませんね。

通常の変数で作業することを妨げるものは全くありません。インタラクティブな指標では、基本的に外部 const パラメータは不要であり、インタラクティブ性によって制御されることはありません。

代替手段があるから使わないという不合理な冗長性を要求しているだけの怠惰な人。

 
Joo Zepper:
複数台のモニターをお持ちの方へのアドバイスをお願いします。端末を使った効率的な作業を行うにはどうすればよいのでしょうか?

すべてのタブとサービスウィンドウ(ツールボックス、テスター、市場概観、ナビゲーター、データウィンドウ、ツールバー)は、別のモニターに配置する必要があります。

ターミナルウィンドウにチャートだけを残す。同じサイズと解像度を持つ複数のモニターでターミナルウィンドウを引き伸ばすことができる

 
o_O:

なぜこのイベントがMTにないのか、説明を求めないほうがいい。

サービスデスクに、どのように機能するべきだと考えているのか、なぜ99%のトレーダーがそれを必要としているのか、詳しい説明を書いてください。

o_o

通常の変数で動作させることを妨げるものは何もありません。インタラクティブな指標では、基本的に、インタラクティブ性によって制御されない外部パラメータは必要ありません。

あなたは怠け者で、すでに実行可能な代替手段があるため、あなた自身が使わない不合理な冗長性を要求しているだけです。

冷静な理性に対して、このような攻撃的な認識は理解できない。何かおかしいと思ったんだろう...。ありません、すべて順調です、落ち着いてください。あなたはR...

マキシム・フローレンコ
ここでOnTimer()を使って、Xミリ秒ごとにイベントを呼び出せばいいと思うんです。
o_o
このソリューションはすでに、より正確に開発されています - 必要なシンボルにインジケータを置き、Expert Advisorにカスタムイベントを 送信します。

そうなんです、だからストレートに書いたんです。

zaskok3 です。

なぜか、彼らはタイマーやもっと大きな倒錯であるOnChartEventを使った解決策を提供しています。

スラワ、あなたの論理がよくわからない。

スラワ

他人のキャラクターからダニを欲しがる論拠は何でしょうか?"景品に遅れるかもしれないから、正しいキャラクターを把握するためにタイマーを回したくない"。また、他人のシンボルのティックイベント(特に複数のシンボルを監視している場合)は、別のイベントの独自の処理によってキューに遅れることがあるため、景品に遅れる確率が非常に高くなります。

信じてください、私たちは他人のチックについてイベントを 議論しました。だから、「タイマーを使ったほうがよっぽど いい」という結論に至ったのです。

では、タイマーも自分自身のティックで 十分なのに、OnTickを持つ目的は何なのでしょうか?私の論理が誤って働いているのかもしれません。しかし、私の推論は次のようなものです。OnTickがある以上、OnMarketWatchもあるはずです。OnMarketWatchはOnTimerで実装できるので、同じことをOnTickで行うことができます。つまり、OnTickの存在は、OnMarketWatchの存在と同じ理屈になるのです。しかし、一方は存在し、他方は存在しない。

OnTickキューは、現在のOnTickが実行された時点のティックを0にリセットします(EAではそうなっています)。どのようなキューのオーバーフローを言っているのかが不明です。週末にタイマーをアイドリングさせるのは合理的ではありません。そして、EAはすべてのティックでOnTickをトリガーするわけではありません。EAでスキップのないティックを集めることができないのは、このためです。キューがクリアされるのは正常です。オーバーフローはありません。

 

zaskok3:

スラワ、あなたの論理がよくわからない。

では、タイマーはそれ自身のティックでも 十分なのに、OnTickを持つ目的は何なのでしょうか?私の論理が、おそらく正しく働いていないのでしょう。しかし、私の推論は次のとおりです。OnTickがあるならOnMarketWatchもあるはずです。OnMarketWatchはOnTimerで実装できるので、同じことをOnTickで行うことができます。つまり、OnTickの存在は、OnMarketWatchの存在と同じ理屈になるのです。しかし、一方は存在し、他方は存在しない。

OnTickキューは、現在のOnTickが実行された時点のティックについてはゼロにリセットされます(EAではこれが当てはまります)。キューのオーバーフローが何であるかは、明らかではありません。週末にタイマーをアイドリングさせるのは合理的ではありません。そして、EAはすべてのティックでOnTickをトリガーするわけではありません。EAでティックをスキップせずに収集することができないのはこのためです。キューがクリアされるのは正常です。オーバーフローはありません。

OnTickは4重のスタート機能からシームレスに移動しました

OnTickはニーズの99%をカバーし、簡単なプログラムを書くことができます。

キューを溢れさせることが目的ではありません。かさ上げすることです。イベントはなくなるものではありません。

個々のイベントに対する個別のキュー(OnTickキュー)は存在しない。同じExpert Advisorのすべてのイベントに対して、1つの共通のキューが存在します。

しかし、キューには非常にインテリジェントにイベントが補充されます。キューに生のNewTick イベントがある場合、他のNewTickイベントは追加されないのです。キューに生のTimerイベントがある場合、他のTimerイベントはキューに追加されません。などなど。

タイマーの合理性・不合理性について。実は、タイマーは思ったほどリソースを消費しない。ちなみに、クライアント端末は、自分の必要に合わせて複数のタイマーを同時に動かしている。常に動作し、プロセッサーの負荷は0です。

 
Slawa:

OnTickはニーズの99%をカバーし、簡単なプログラムを書くことができます。

99%は、タイマーの初期化を別のもの(1行)にして、ソースコードのOnTickをOnTimerにリネームしても、結果は変わらず、以前と同様に動作し、プログラムはシンプルなままです。

OnTickは4重のスタート機能からシームレスに移行しました

今のは「イエス」です。ほとんどの人はもっと慣れているはずです。それが一番の理由です。

分かりやすい説明のために、多くの注意を傾けていただき、ありがとうございます。タイマーによる人工的なOnMarketWatchの実装のソースコードを追加してほしいという要望があります。私の実装では、すべてのシンボルの前のティックを記憶し、タイマーの各ステップで現在の値と比較する必要があります。異なる場合は、OnMarketWatch を呼び出すイベントを生成する。そして、まさにこの行動は理不尽に思える。つまり、出力時にOnTimerを無為に実行することはできないのです。私たちは比較し続けなければならないのです。もしかしたら、もっといい解決策があるかもしれません。だから、その変種を見せろということなんです。あなたならどうする。


やはりOnChartEventを 使った自転車は曲者だと思います。Market Watchの文字の数だけチャートを開く必要があるため。

 
友人たちよ、おそらく本当に逆説的な状況があるのだろう。
理論的には、もし私の理解が正しければ、シグナル購読者が自分の口座のレバレッジを1:200から1:500に上げると、少なくとも2倍のオープニングボリュームになるはずです。
預金残高も同じで、預金残高を増やせば、体積も増えるはずです。
私の購読者の一人が、レバレッジを1:200から1:500に、負荷を50%から90%に増やしたと書いています。しかし、その後、オープンポジションの数量はどの方向にも変化していません。そして、彼のアカウントの残高は、それを可能にする以上のものであったはずです。
もしかして、私がコピーシステムを正しく理解していないのでしょうか?
 
Artem Prischepa:
...
想像上の(あるいは架空の)購読者に代わって質問するのはやめてください。購読者から質問があれば、自分で質問させればいいのです。そうでなければ、信号の宣伝と見なします。