イベントの流れ イベントの制御やアイドリングストップはどのように行うのですか？(+解決済み) - ページ 2 1234567 新しいコメント --- 2011.11.02 00:09 #11 Yedelkin:そのため、端末のイベントキューをオーバーフローさせないために、どの程度の頻度でユーザーイベントを 送ればよいのか、まだ不明な点があります...。 私の書き込みを読んでないのは一目瞭然です。 Renat Fatkhullin 2011.11.02 01:28 #12 Yedelkin: イベントキューのオーバーフローがRAMサイズにどのような影響を与えるのか、という質問に対する答えが見つからないのですが。イベントキューが一杯になった場合、キューから溢れたイベントはどこに行くのでしょうか？たまたま「歴史から外れた」イベントのために確保されたRAMの一部は解放されているのでしょうか？ 私の質問は、用語的には正しくないかもしれませんが、問題の本質を捉えていると思います（期待）。キューは動的であり、必然的に大きくなる。 しかし、ある限界に達すると、これ以上キューをロードする意味がないことが明らかになるため、新しいイベントは破棄される。 Yedelkin 2011.11.02 08:15 #13 sergeev: 私の書き込みを読んでいないことはすぐにわかります。 なぜ「読まなかった」のか？あなたは自分の問題を解決し、私は別の種類の問題を解決しようとしている。ディスカッションを読んでも、私の疑問に対する答えは見つかりませんでした。 私の本題に答えていない。:/まさに「一目瞭然」ですね :) Yedelkin 2011.11.02 09:31 #14 Renat: キューは動的であり、必然的に大きくなる。 しかし、ある限界に達すると、これ以上キューをロードする意味がないことが明らかになるため、新しいイベントは破棄される。 OK、キューは "ダイナミック "です。ある「一定の」限度額まで増加する。しかし、なぜ誰も、イベントキューのオーバーフローがメモリサイズにどのように影響 するかという、一見単純な疑問に答えられないのでしょうか？ 補足：オーバーフローしたイベントキューを「維持」するために必要なRAMはどのくらいですか？ もし「ある限界で新しいイベントが破棄される」場合、これらの破棄されたイベント用に以前割り当てられていたRAMは解放されますか？ 質問の目的：ユーザーイベントストリームが、端末が消費するRAMの量をどのように増やす（増加させる）ことができるかを理解する。 Rashid Umarov 2011.11.02 09:50 #15 Yedelkin: イベントキューが満杯になった場合、キューから溢れたイベントはどこに行くのでしょうか？履歴が残らない」イベントのために確保されたRAMの一部は解放されているのでしょうか？ 私の質問は、用語的には正しくないかもしれませんが、問題の本質を伝えている（と思う）のです。Program Execution というセクションで、キューがオーバーフローすると 新しいイベントが破棄されると書かれています。クライアント端末は、発生したイベントを適切なオープングラフに送信する。イベントは、チャート（チャートイベント）またはmql5プログラム（カスタムイベント）によっても生成できます。チャートのCHART_EVENT_OBJECT_CREATE 及びCHART_EVENT_OBJECT_DELETE プロパティを設定することで、チャート上のグラフィカル オブジェクトの作成及び削除のイベント生成を有効／無効にすることができます。各mql5-programと各チャートは独自のイベントキューを持ち、そこにすべての新しいイベントが保存されます。 プログラムは、実行中のチャートからのイベントのみを受信します。すべてのイベントは、受信した順に順次処理されます。キューに既にイベントNewTickが ある場合、またはこのイベントが処理中の場合、新しいイベントNewTickはmql5-programのキューに配置されない。同様に、mql5-programのキューがすでにChartEvent イベントを含んでいるか、イベントが処理中の場合、このタイプの新しいイベントはキューに入れられない。 イベントキューのサイズは限られていますが、十分な大きさがありますので、正しく書かれたプログラムであれば、キューがオーバーフローすることはまずないでしょう。キューがオーバーフローすると、新しいイベントはキューに入れられずに廃棄される。 イベント処理に無限ループを使用することは、非常に推奨されません。このルールの唯一の例外は、1つのStart イベントを処理するスクリプトです。 ライブラリは イベントを処理しません。 --- 2011.11.02 10:41 #16 Yedelkin: なぜ「読まなかった」のか？あなたは自分の問題を解決し、私は別の種類の問題を解決しようとしている。ディスカッションを読んでも、私の疑問に対する答えは見つかりませんでした。 私の本題に答えていない。:/ 確かに「すぐわかる」でしたね :)ユーザーイベントが キューから溢れないように送信する頻度はどの程度が目安か」というご質問です。1ページ目の私の答えは「OnChartEventの呼び出しの頻度で」です。つまり、1つのイベントは1つのOnChartEventです。 間に2つ以上のイベントがあってはいけません。計算方法は以上です。 もう一度、最初のページを読んでみてください。ユーザーイベントの代わりに端末イベントを処理する場合、ユーザーイベントの蓄積を回避する方法を示しました。というくらいにシンプルです。 TheXpert 2011.11.02 11:26 #17 Yedelkin:質問の目的：ユーザーイベントの スレッドが、端末が消費するRAMのサイズをどのように増加（増加）させるかを理解すること。なぜ？まあ、そうなんですけどね。問題の値段は数メガバイトです。それは問題ないというか、あまり関係ないですね。 Yedelkin 2011.11.02 11:45 #18 Rosh: プログラム実行という 項目がありますが、これは...。 1.ハンドブックセクションが大幅に変更されました。 1.1 例えば、以前は「クライアント端末は、発生したイベントを全て共通のキューに 入れる。このように、イベントは到着順に次々と処理される。 例外は NewTickイベントです。キューに既にそのようなイベントがある場合、またはこのイベントが処理中の場合、新しいNewTickイベントはキューに 入れられない"。 現在：「プログラムは、実行中のチャートからのみイベントを受信 します。 すべてのイベントは、受信した順番に次々と処理 されます。キューに既にイベント NewTickが あるか、このイベントが処理中である場合、新しいイベントNewTickはmql5-programのキューに 入れられない。同様に、mql5-programのキューに既にイベント ChartEventが あるか、そのようなイベントが処理中の 場合 、このタイプの新しいイベントは キューに入れられない。 See the difference」という言葉があるように、「違いを見る」のです。警告くらいはしてほしい。:/ この変更により、カスタムイベントの扱い方が根本的に変わりました。 1.2.次に進みます。イベントの取捨選択の原則がひっくり返ります。以前は、「イベントキューのサイズには制限があります。キューが一杯になると、古い イベントは処理さ れずに削除され、新しい受信イベントのためのスペースが確保される」。 現在：「キューが一杯になると、新しい イベントはキューに入れずに破棄されます。 彼らが言うように、ありがとう：最も関連性の高いユーザーイベントを失うことになるのです。 2.ハンドブックの引用部分は、私の基本的な疑問に対する答えになっていません。イベントキューのオーバーフローは、RAMサイズにどのような影響を与えますか？溢れたイベントキューを「維持」するために必要なRAMはどのくらいですか？ もし「ある限界に達すると新しいイベントは破棄される」場合、その破棄されたイベントのために以前割り当てられていたRAMは解放されるのでしょうか？ Yedelkin 2011.11.02 11:50 #19 TheXpert: イェデルキン 質問の目的：ユーザーイベントの ストリームが、端末が消費するRAMのサイズをどのように増加（増加）させるかを理解すること。 なぜ？まあ、そうなんですけどね。この質問は数メガバイトの価値があります。 奇妙な質問："なぜ？"- 答えは、「結論を出すために理解すること」です。 Rashid Umarov 2011.11.02 11:57 #20 Yedelkin:2.ハンドブックに引用されている部分は、私の主な疑問に対する答えになっていません。イベントキューのオーバーフローは、RAMサイズにどのような影響を与えますか？溢 れたイベントキューを「維持」するために必要なRAMはどのくらいですか？ もし「ある限界に達すると新しいイベントは破棄される」場合、その破棄されたイベントのために以前割り当てられていたRAMは解放されるのでしょうか？そのような問題が発生すると、事態は非常にまずいことになります。イベントキューが溢れているのは、メモリの問題を探す最後の場所だと思うのです。イベントが破棄されるということは、キューに入れられなくなっただけです。メモリが増えない。 1234567 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
Yedelkin:
そのため、端末のイベントキューをオーバーフローさせないために、どの程度の頻度でユーザーイベントを 送ればよいのか、まだ不明な点があります...。
イベントキューのオーバーフローがRAMサイズにどのような影響を与えるのか、という質問に対する答えが見つからないのですが。イベントキューが一杯になった場合、キューから溢れたイベントはどこに行くのでしょうか？たまたま「歴史から外れた」イベントのために確保されたRAMの一部は解放されているのでしょうか？
私の質問は、用語的には正しくないかもしれませんが、問題の本質を捉えていると思います（期待）。
キューは動的であり、必然的に大きくなる。
しかし、ある限界に達すると、これ以上キューをロードする意味がないことが明らかになるため、新しいイベントは破棄される。
私の書き込みを読んでいないことはすぐにわかります。
なぜ「読まなかった」のか？あなたは自分の問題を解決し、私は別の種類の問題を解決しようとしている。ディスカッションを読んでも、私の疑問に対する答えは見つかりませんでした。
私の本題に答えていない。:/まさに「一目瞭然」ですね :)
キューは動的であり、必然的に大きくなる。
しかし、ある限界に達すると、これ以上キューをロードする意味がないことが明らかになるため、新しいイベントは破棄される。
OK、キューは "ダイナミック "です。ある「一定の」限度額まで増加する。しかし、なぜ誰も、イベントキューのオーバーフローがメモリサイズにどのように影響 するかという、一見単純な疑問に答えられないのでしょうか？
補足：オーバーフローしたイベントキューを「維持」するために必要なRAMはどのくらいですか？ もし「ある限界で新しいイベントが破棄される」場合、これらの破棄されたイベント用に以前割り当てられていたRAMは解放されますか？
質問の目的：ユーザーイベントストリームが、端末が消費するRAMの量をどのように増やす（増加させる）ことができるかを理解する。
イベントキューが満杯になった場合、キューから溢れたイベントはどこに行くのでしょうか？履歴が残らない」イベントのために確保されたRAMの一部は解放されているのでしょうか？
私の質問は、用語的には正しくないかもしれませんが、問題の本質を伝えている（と思う）のです。
Program Execution というセクションで、キューがオーバーフローすると 新しいイベントが破棄されると書かれています。
クライアント端末は、発生したイベントを適切なオープングラフに送信する。イベントは、チャート（チャートイベント）またはmql5プログラム（カスタムイベント）によっても生成できます。チャートのCHART_EVENT_OBJECT_CREATE 及びCHART_EVENT_OBJECT_DELETE プロパティを設定することで、チャート上のグラフィカル オブジェクトの作成及び削除のイベント生成を有効／無効にすることができます。各mql5-programと各チャートは独自のイベントキューを持ち、そこにすべての新しいイベントが保存されます。
プログラムは、実行中のチャートからのイベントのみを受信します。すべてのイベントは、受信した順に順次処理されます。キューに既にイベントNewTickが ある場合、またはこのイベントが処理中の場合、新しいイベントNewTickはmql5-programのキューに配置されない。同様に、mql5-programのキューがすでにChartEvent イベントを含んでいるか、イベントが処理中の場合、このタイプの新しいイベントはキューに入れられない。
イベントキューのサイズは限られていますが、十分な大きさがありますので、正しく書かれたプログラムであれば、キューがオーバーフローすることはまずないでしょう。キューがオーバーフローすると、新しいイベントはキューに入れられずに廃棄される。
イベント処理に無限ループを使用することは、非常に推奨されません。このルールの唯一の例外は、1つのStart イベントを処理するスクリプトです。
ライブラリは イベントを処理しません。
なぜ「読まなかった」のか？あなたは自分の問題を解決し、私は別の種類の問題を解決しようとしている。ディスカッションを読んでも、私の疑問に対する答えは見つかりませんでした。
私の本題に答えていない。:/ 確かに「すぐわかる」でしたね :)
ユーザーイベントが キューから溢れないように送信する頻度はどの程度が目安か」というご質問です。
1ページ目の私の答えは「OnChartEventの呼び出しの頻度で」です。
つまり、1つのイベントは1つのOnChartEventです。 間に2つ以上のイベントがあってはいけません。
計算方法は以上です。
もう一度、最初のページを読んでみてください。ユーザーイベントの代わりに端末イベントを処理する場合、ユーザーイベントの蓄積を回避する方法を示しました。というくらいにシンプルです。
質問の目的：ユーザーイベントの スレッドが、端末が消費するRAMのサイズをどのように増加（増加）させるかを理解すること。
なぜ？まあ、そうなんですけどね。問題の値段は数メガバイトです。
それは問題ないというか、あまり関係ないですね。
プログラム実行という 項目がありますが、これは...。
1.ハンドブックセクションが大幅に変更されました。
1.1 例えば、以前は「クライアント端末は、発生したイベントを全て共通のキューに 入れる。このように、イベントは到着順に次々と処理される。 例外は NewTickイベントです。キューに既にそのようなイベントがある場合、またはこのイベントが処理中の場合、新しいNewTickイベントはキューに 入れられない"。
現在：「プログラムは、実行中のチャートからのみイベントを受信 します。 すべてのイベントは、受信した順番に次々と処理 されます。キューに既にイベント NewTickが あるか、このイベントが処理中である場合、新しいイベントNewTickはmql5-programのキューに 入れられない。同様に、mql5-programのキューに既にイベント ChartEventが あるか、そのようなイベントが処理中の 場合 、このタイプの新しいイベントは キューに入れられない。
See the difference」という言葉があるように、「違いを見る」のです。警告くらいはしてほしい。:/ この変更により、カスタムイベントの扱い方が根本的に変わりました。
1.2.次に進みます。イベントの取捨選択の原則がひっくり返ります。以前は、「イベントキューのサイズには制限があります。キューが一杯になると、古い イベントは処理さ れずに削除され、新しい受信イベントのためのスペースが確保される」。
現在：「キューが一杯になると、新しい イベントはキューに入れずに破棄されます。 彼らが言うように、ありがとう：最も関連性の高いユーザーイベントを失うことになるのです。
2.ハンドブックの引用部分は、私の基本的な疑問に対する答えになっていません。イベントキューのオーバーフローは、RAMサイズにどのような影響を与えますか？溢れたイベントキューを「維持」するために必要なRAMはどのくらいですか？ もし「ある限界に達すると新しいイベントは破棄される」場合、その破棄されたイベントのために以前割り当てられていたRAMは解放されるのでしょうか？
TheXpert:
質問の目的：ユーザーイベントの ストリームが、端末が消費するRAMのサイズをどのように増加（増加）させるかを理解すること。
なぜ？まあ、そうなんですけどね。この質問は数メガバイトの価値があります。
2.ハンドブックに引用されている部分は、私の主な疑問に対する答えになっていません。イベントキューのオーバーフローは、RAMサイズにどのような影響を与えますか？溢 れたイベントキューを「維持」するために必要なRAMはどのくらいですか？ もし「ある限界に達すると新しいイベントは破棄される」場合、その破棄されたイベントのために以前割り当てられていたRAMは解放されるのでしょうか？
そのような問題が発生すると、事態は非常にまずいことになります。イベントキューが溢れているのは、メモリの問題を探す最後の場所だと思うのです。
イベントが破棄されるということは、キューに入れられなくなっただけです。メモリが増えない。