OnBookEventのサブスクリプションが落ちることがあるのですが、そのようなことはあるのでしょうか? - ページ 2 123456789...14 新しいコメント A100 2018.07.21 16:51 #11 Stanislav Korotky:"一人の専門家が配信を停止すれば、他の専門家も配信を停止する"? それは間違いない Sergey Savinkin 2018.07.21 16:57 #12 Stanislav Korotky:価値があるかどうかはあくまで推測ですが、「あるEAがイベントの受信を停止するだけで、他のEAもすべて受信を停止する」ということを続けている例で言うと?そんなのありえないと思う、バグでしょう(笑)。ひとつは、チェックが簡単なこと。自分でやりたいのですが、FORTSのアカウントしか持っていないので、週末はお休みなんです。 しかし、もしそうなら、その状況は面白いことになる。Expert Advisor とインジケータを有効にすると、サブスクリプションがトリガーされました。Expert AdvisorやIndicatorを無効にすると、サブスクリプションがクラッシュしたと既に書かれています。これは、放送が逆方向にも作用していることを示唆している。ここで、何かが変わったとします(例えば、履歴が変わり、インジケータが再計算された)。しかし、OnInitとOnDeinitはランダムに呼び出せることが分かっています。正しい場合もあれば、その逆の場合もあります。チャートが新しいバージョンのインジケータを最初に呼び出し、その後、古いインジケータをアンインストールした場合、どうなりますか?加入が落ちます。それこそ「静かに落ちていく」ような感じでしょうか。株価が来なくなったときのために、OnInitとOnDeinitにプリンターを入れて、キューとメッセージをチェックすることをお勧めします。もしかしたら、問題がクリアになるかもしれません。 A100 2018.07.21 17:32 #13 Sergey Savinkin:まず、確認が簡単なこと。自分でやりたいのですが、FORTSにしかアカウントを持っていないので、週末はお休みです。CHARTEVENT_OBJECT_CREATE を使わなくても、スコアの確認は全く問題ありません。 Алексей Тарабанов 2018.07.21 19:12 #14 https://yandex.ru/images/search?source=wiz&text=два%20выключателя%20на%20одну%20лампочку&img_url=https%3A%2F%2Frepair-need.ru%2Fuploads%2Fdico-kebfbf.jpg&pos=3&rpt=simage&lr=213 Яндекс.Картинки yandex.ru Результаты поиска по запросу "два выключателя на одну лампочку" в Яндекс.Картинках TheXpert 2018.07.21 20:17 #15 A100: 当たり前のことなのですがよくわからないけど、いつでもリンクカウンターをつけられるように A100 2018.07.21 21:20 #16 TheXpert:よくわからないけど、いつでもリンクカウンターをつけられるようにカウンターはありません。そして、もしあれば、その存在とAddReleaseペアの呼び出しの可否について、ドキュメントに明示されるでしょう。 そして、リファレンスカウンターが必要だと言うのなら...。それならいっそのこと、放送を全廃してしまえばいい。 TheXpert 2018.07.22 13:08 #17 A100:カウンターはありません。また、もしあったとしても、それが存在し、Add/Releaseのペアコールだけが許されることがドキュメントに明記されているはずです。そうでなければ、カウンターは失われ、その存在意義が失われることになりますで、今は誰でも退会できるというロジックがナンセンスなので、リリース機能は無意味です。 Ilya Baranov 2018.07.22 13:42 #18 単純にMarketBookRelease 関数を使わないという提案もあります。 理論的には、端末やサーバーのリソースの一部を無駄にすることになります。 しかし、実際には...これによって、何か実際の結果が出るのでしょうか? A100 2018.07.22 17:56 #19 TheXpert:誰でも退会できるというロジックはナンセンスなロジックなので、リリース機能の意味がない。 たとえカウンターがあったとしても、誰でも 何 度でもリリースに 電話すれば退会できます。ほとんどの場合、カウンターは余分な電話を検出できず、現在の問題はカウンターの誤動作の問題に変わって しまうでしょう。また、スマートカウンターが使えるようになれば、そのような放送を廃止することも可能です。 Stanislav Korotky 2018.07.22 18:51 #20 ハリネズミのために説明しても無意味なので、他の人のために書きます ;-)。 イベントブロードキャストの概念と、イベントに対するsubscribeとunsubscribeの関数をペアコールする原理は別物である。これらは意味的に独立した技術であり、互いに影響しあう必要はなく、理想的には影響しあうべきではありません。イベントをブロードキャストさせる(これは効率化のために行われたのだろうが、非常に議論があり、実装を誤ると今回のような問題を引き起こす可能性がある)。つまり、一人が申し込むだけで、全員がイベントを受け取ることができるのです。しかし、逆に言えば、一人が退会すると全員がダメになる、それはもうある種のナローキャスティングなのです。 ドキュメントにある契約者数のカウンターについては、非常に重要であるにもかかわらず、言及されていません(また、放送に関するフレーズは、上記の理由による説明ではありません)。ブロードキャストは理想的には購読者数が0になるまで続くべきです。 そうでなければ、(異なる開発者のものも含めて)MQLプログラムが互いの仕事に害を与えないように、何らかの形で通信しなければならないのは明らかですが、これはナンセンスです。このような形でサブスクリプションが実装されたソフトウェア(MTやWindowsなどに限らない広義の)の例を、私はひとつも知りません。 MarketBookReleaseについて、こんな一節がある。 Обычно эта функция должна вызываться из функции OnDeinit() в том случае, если в функции OnInit() была вызвана соответствующая функция MarketBookAdd(). また、曖昧な表現になってしまいます。加入者数をコントロールしていると解釈することもできる。でも、このソフトは私的な解釈を許さないんです。 結論から言うと、IMHOは、実装はレーキ(MQLレベルで検証とオーバーサブスクリプションが必要)、ドキュメントは濁り。悪意のある、あるいは明らかに悪いコードは、カウンターを使用しても他人の購読を停止させることができるという主張は、実際には関係ないものです。そのようなスクリプトはすべて、ターミナルの他の多くの場所で害を及ぼす可能性があります(例えば、他の人のオブジェクトを削除する、他の人の位置のストップを殺すなど、これまでに100万回起こったことがあります)。このようなあからさまなピギーバックの発現については、ユーザーの規律、他のユーザーのコードの校正(もしあれば)、デモでのチェック以外では防ぐことができませんので、お話する意味がありません。今問題になっているのは、きちんと書かれたコードがまともに動かないことです。 この仕組みをきちんとやるなら、もちろん--パブリッシャー/サブスクライバーのパターンが廃止されたわけではありません。確かに効率には影響しないでしょう。 123456789...14 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
"一人の専門家が配信を停止すれば、他の専門家も配信を停止する"?
価値があるかどうかはあくまで推測ですが、「あるEAがイベントの受信を停止するだけで、他のEAもすべて受信を停止する」ということを続けている例で言うと?そんなのありえないと思う、バグでしょう(笑)。
ひとつは、チェックが簡単なこと。自分でやりたいのですが、FORTSのアカウントしか持っていないので、週末はお休みなんです。
しかし、もしそうなら、その状況は面白いことになる。Expert Advisor とインジケータを有効にすると、サブスクリプションがトリガーされました。Expert AdvisorやIndicatorを無効にすると、サブスクリプションがクラッシュしたと既に書かれています。これは、放送が逆方向にも作用していることを示唆している。ここで、何かが変わったとします(例えば、履歴が変わり、インジケータが再計算された)。しかし、OnInitとOnDeinitはランダムに呼び出せることが分かっています。正しい場合もあれば、その逆の場合もあります。チャートが新しいバージョンのインジケータを最初に呼び出し、その後、古いインジケータをアンインストールした場合、どうなりますか?加入が落ちます。それこそ「静かに落ちていく」ような感じでしょうか。株価が来なくなったときのために、OnInitとOnDeinitにプリンターを入れて、キューとメッセージをチェックすることをお勧めします。もしかしたら、問題がクリアになるかもしれません。
まず、確認が簡単なこと。自分でやりたいのですが、FORTSにしかアカウントを持っていないので、週末はお休みです。
CHARTEVENT_OBJECT_CREATE を使わなくても、スコアの確認は全く問題ありません。
当たり前のことなのですが
よくわからないけど、いつでもリンクカウンターをつけられるように
よくわからないけど、いつでもリンクカウンターをつけられるように
カウンターはありません。そして、もしあれば、その存在とAddReleaseペアの呼び出しの可否について、ドキュメントに明示されるでしょう。
そして、リファレンスカウンターが必要だと言うのなら...。それならいっそのこと、放送を全廃してしまえばいい。
カウンターはありません。また、もしあったとしても、それが存在し、Add/Releaseのペアコールだけが許されることがドキュメントに明記されているはずです。そうでなければ、カウンターは失われ、その存在意義が失われることになります
で、今は誰でも退会できるというロジックがナンセンスなので、リリース機能は無意味です。
単純にMarketBookRelease 関数を使わないという提案もあります。
理論的には、端末やサーバーのリソースの一部を無駄にすることになります。
しかし、実際には...これによって、何か実際の結果が出るのでしょうか?
誰でも退会できるというロジックはナンセンスなロジックなので、リリース機能の意味がない。
ハリネズミのために説明しても無意味なので、他の人のために書きます ;-)。
イベントブロードキャストの概念と、イベントに対するsubscribeとunsubscribeの関数をペアコールする原理は別物である。これらは意味的に独立した技術であり、互いに影響しあう必要はなく、理想的には影響しあうべきではありません。イベントをブロードキャストさせる(これは効率化のために行われたのだろうが、非常に議論があり、実装を誤ると今回のような問題を引き起こす可能性がある)。つまり、一人が申し込むだけで、全員がイベントを受け取ることができるのです。しかし、逆に言えば、一人が退会すると全員がダメになる、それはもうある種のナローキャスティングなのです。
ドキュメントにある契約者数のカウンターについては、非常に重要であるにもかかわらず、言及されていません(また、放送に関するフレーズは、上記の理由による説明ではありません)。ブロードキャストは理想的には購読者数が0になるまで続くべきです。 そうでなければ、(異なる開発者のものも含めて)MQLプログラムが互いの仕事に害を与えないように、何らかの形で通信しなければならないのは明らかですが、これはナンセンスです。このような形でサブスクリプションが実装されたソフトウェア(MTやWindowsなどに限らない広義の)の例を、私はひとつも知りません。
MarketBookReleaseについて、こんな一節がある。
Обычно эта функция должна вызываться из функции OnDeinit() в том случае, если в функции OnInit() была вызвана соответствующая функция MarketBookAdd().
また、曖昧な表現になってしまいます。加入者数をコントロールしていると解釈することもできる。でも、このソフトは私的な解釈を許さないんです。
結論から言うと、IMHOは、実装はレーキ(MQLレベルで検証とオーバーサブスクリプションが必要)、ドキュメントは濁り。悪意のある、あるいは明らかに悪いコードは、カウンターを使用しても他人の購読を停止させることができるという主張は、実際には関係ないものです。そのようなスクリプトはすべて、ターミナルの他の多くの場所で害を及ぼす可能性があります(例えば、他の人のオブジェクトを削除する、他の人の位置のストップを殺すなど、これまでに100万回起こったことがあります)。このようなあからさまなピギーバックの発現については、ユーザーの規律、他のユーザーのコードの校正(もしあれば)、デモでのチェック以外では防ぐことができませんので、お話する意味がありません。今問題になっているのは、きちんと書かれたコードがまともに動かないことです。
この仕組みをきちんとやるなら、もちろん--パブリッシャー/サブスクライバーのパターンが廃止されたわけではありません。確かに効率には影響しないでしょう。