对OnBookEvent的订阅有时会脱落--有这种情况吗？ - 页 2 123456789...14 新评论 A100 2018.07.21 18:51 #11 Stanislav Korotky:"只要有一位专家取消订阅，其他专家也会停止接收该事件"？ 这是一个没有问题的问题 Sergey Savinkin 2018.07.21 18:57 #12 Stanislav Korotky:这只是一个猜测，是否值得--在继续 "只需要一个EA取消接收事件，其他所有的EA也会停止接收 "的比喻？我认为不可能有这样的事情，这将是（或者说是）一个错误。首先，它很容易检查。我想自己做，但我只有一个FORTS账户，而且周末关闭。 但如果是这样，情况就会变得很有趣。当你启用了专家顾问和指标，订阅就已经触发了。当你禁用专家顾问或指标时，你已经写了，订阅已经崩溃了。这表明，广播确实在相反的方向上发挥作用。现在想象一下，有些事情已经发生了变化（例如，历史已经改变，指标已经被重新计算）。但我们知道，OnInit和OnDeinit可以被随机调用。有时是正确的，有时反之亦然。如果图表先调用新版本的指标，然后再卸载旧版本的指标，会发生什么？订阅会脱落。这就是 "悄悄地掉下来 "的感觉。我建议你在OnInit和OnDeinit中放入打印机，以检查队列和消息，以防股票报价停止进入。也许这个问题会得到解决。 A100 2018.07.21 19:32 #13 Sergey Savinkin:首先，这很容易检查。我想自己做，但我只有一个FORTS的账户，而且周末是关闭的。你根本不需要CHARTEVENT_OBJECT_CREATE 来检查分数。 Алексей Тарабанов 2018.07.21 21: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 22:17 #15 A100: 这是一个不难理解的问题。我不明白，你总是可以把一个链接计数器 A100 2018.07.21 23:20 #16 TheXpert:我不明白，你总是可以把一个链接计数器没有计数器。如果有的话，在文档中会明确说明它的存在和只接受Add/Release对的调用--否则计数器会被破坏，它存在的意义也会消失。 如果你说你需要一个参考计数器...那么你可以更进一步，完全废除广播。 TheXpert 2018.07.22 15:08 #17 A100:没有计数器。而如果有的话，在文档中会明确说明它的存在，并且只允许添加/释放配对调用--否则计数器会丢失，它存在的意义也会消失而现在，发布功能是没有意义的，因为任何人都可以取消订阅你的事件的逻辑是无稽之谈。 Ilya Baranov 2018.07.22 15:42 #18 有一个简单的建议，就是干脆不使用MarketBookRelease 函数。 从理论上讲，这将浪费一些终端和服务器的资源。 但在实践中...这是否会有任何真正的后果？ A100 2018.07.22 19:56 #19 TheXpert:现在发布功能已经没有意义了。因为任何人都可以取消订阅你的活动的逻辑是无稽之谈。 即使有一个计数器，任何人都可以根据需要多次 呼叫释放 来取消订阅--很可能计数器无法检测到额外的呼叫，目前的问题就会变成一个计数器故障的问题。如果你能使用一个智能计数器，你就可以取消这样的广播。 Stanislav Korotky 2018.07.22 20:51 #20 为刺猬解释是没有意义的，所以我就为别人写;-)。 事件广播的概念是一回事，但将订阅和取消订阅功能与事件配对的原则是另一回事。这些都是语义上独立的技术，它们不必，而且理想上也不应该相互影响。让事件被广播（这可能是出于效率的考虑，但这是非常有争议的，如果实施不当，会导致目前的问题）。这意味着只要有一个人订阅，所有的人都能收到该事件。但反过来说--一个人必须取消订阅，每个人都会被坑--这已经是某种狭义的广播了。 关于文档中用户的计数器没有提到，尽管它非常重要（关于广播的短语不是对上述原因的解释）。广播最好能持续到订阅者的数量减少到0。否则，很明显，MQL程序（包括来自不同开发者的程序）将不得不以某种方式相互沟通，以便不损害他们的工作，但这是无稽之谈。我不知道有哪个软件（广义的，不限于MT、Windows等）的订阅是以这种方式实现的。 有这样一段关于MarketBookRelease的内容。 Обычно эта функция должна вызываться из функции OnDeinit() в том случае, если в функции OnInit() была вызвана соответствующая функция MarketBookAdd(). 这又是一个含糊不清的问题。它可以被解释为对订阅的数量有控制权。但该软件不允许私人解释。 底线，IMHO，实施是一个耙子（在MQL级别需要验证和超额订阅），文档是模糊的。恶意的或彻头彻尾的坏代码即使有计数器也能杀死别人的订阅，这种说法其实并不相关。所有这样的脚本都可能在终端的其他一堆地方造成伤害（例如，删除其他人的对象，在其他人的位置上杀死停止，等等，这在以前已经发生过无数次）。谈论这种彻头彻尾的捎带表现是没有意义的--除了用户纪律、校对其他用户的代码（如果有的话）或在演示中检查之外，它们是无法被阻止的。现在的问题是，正确编写的代码现在无法正常运行。 如果我们要正确地做这个机制，当然--发布者/订阅者模式并没有被废除。这当然不会影响效率。 123456789...14 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
"只要有一位专家取消订阅，其他专家也会停止接收该事件"？
这只是一个猜测，是否值得--在继续 "只需要一个EA取消接收事件，其他所有的EA也会停止接收 "的比喻？我认为不可能有这样的事情，这将是（或者说是）一个错误。
首先，它很容易检查。我想自己做，但我只有一个FORTS账户，而且周末关闭。
但如果是这样，情况就会变得很有趣。当你启用了专家顾问和指标，订阅就已经触发了。当你禁用专家顾问或指标时，你已经写了，订阅已经崩溃了。这表明，广播确实在相反的方向上发挥作用。现在想象一下，有些事情已经发生了变化（例如，历史已经改变，指标已经被重新计算）。但我们知道，OnInit和OnDeinit可以被随机调用。有时是正确的，有时反之亦然。如果图表先调用新版本的指标，然后再卸载旧版本的指标，会发生什么？订阅会脱落。这就是 "悄悄地掉下来 "的感觉。我建议你在OnInit和OnDeinit中放入打印机，以检查队列和消息，以防股票报价停止进入。也许这个问题会得到解决。
首先，这很容易检查。我想自己做，但我只有一个FORTS的账户，而且周末是关闭的。
你根本不需要CHARTEVENT_OBJECT_CREATE 来检查分数。
这是一个不难理解的问题。
我不明白，你总是可以把一个链接计数器
我不明白，你总是可以把一个链接计数器
没有计数器。如果有的话，在文档中会明确说明它的存在和只接受Add/Release对的调用--否则计数器会被破坏，它存在的意义也会消失。
如果你说你需要一个参考计数器...那么你可以更进一步，完全废除广播。
没有计数器。而如果有的话，在文档中会明确说明它的存在，并且只允许添加/释放配对调用--否则计数器会丢失，它存在的意义也会消失
而现在，发布功能是没有意义的，因为任何人都可以取消订阅你的事件的逻辑是无稽之谈。
有一个简单的建议，就是干脆不使用MarketBookRelease 函数。
从理论上讲，这将浪费一些终端和服务器的资源。
但在实践中...这是否会有任何真正的后果？
现在发布功能已经没有意义了。因为任何人都可以取消订阅你的活动的逻辑是无稽之谈。
为刺猬解释是没有意义的，所以我就为别人写;-)。
事件广播的概念是一回事，但将订阅和取消订阅功能与事件配对的原则是另一回事。这些都是语义上独立的技术，它们不必，而且理想上也不应该相互影响。让事件被广播（这可能是出于效率的考虑，但这是非常有争议的，如果实施不当，会导致目前的问题）。这意味着只要有一个人订阅，所有的人都能收到该事件。但反过来说--一个人必须取消订阅，每个人都会被坑--这已经是某种狭义的广播了。
关于文档中用户的计数器没有提到，尽管它非常重要（关于广播的短语不是对上述原因的解释）。广播最好能持续到订阅者的数量减少到0。否则，很明显，MQL程序（包括来自不同开发者的程序）将不得不以某种方式相互沟通，以便不损害他们的工作，但这是无稽之谈。我不知道有哪个软件（广义的，不限于MT、Windows等）的订阅是以这种方式实现的。
有这样一段关于MarketBookRelease的内容。
Обычно эта функция должна вызываться из функции OnDeinit() в том случае, если в функции OnInit() была вызвана соответствующая функция MarketBookAdd().
这又是一个含糊不清的问题。它可以被解释为对订阅的数量有控制权。但该软件不允许私人解释。
底线，IMHO，实施是一个耙子（在MQL级别需要验证和超额订阅），文档是模糊的。恶意的或彻头彻尾的坏代码即使有计数器也能杀死别人的订阅，这种说法其实并不相关。所有这样的脚本都可能在终端的其他一堆地方造成伤害（例如，删除其他人的对象，在其他人的位置上杀死停止，等等，这在以前已经发生过无数次）。谈论这种彻头彻尾的捎带表现是没有意义的--除了用户纪律、校对其他用户的代码（如果有的话）或在演示中检查之外，它们是无法被阻止的。现在的问题是，正确编写的代码现在无法正常运行。
如果我们要正确地做这个机制，当然--发布者/订阅者模式并没有被废除。这当然不会影响效率。