我的方法。核心是引擎。 - 页 147 1...140141142143144145146147148149150151152153154...184 新评论 Реter Konow 2019.01.14 15:55 #1461 一般来说，这个问题几乎已经解决了。 我们需要EA的每个副本创建两个自己的资源--一个用于向引擎写消息，另一个用于从引擎读取消息。引擎需要在资源中进行循环，看看有多少份EA在不同的对上运行。该引擎将创建一个正在运行的EA的动态列表，用户将通过该列表切换连接。接下来，引擎将记录用于发送消息和接收EA消息的资源的名称。每个EA将正常运行，并以通常的方式向引擎写入它们的信息。引擎只有在连接到该EA时才会读取这些信息。引擎将在连接事件上向EA发送一个命令，引擎将向资源写入一个单独的参数内核。引擎将加载这个内核。接下来，它将循环浏览GUI元素并重新绘制它们，以便它们携带最新的信息。在这之后，引擎将把它的信息写到其资源中的EA中，以接收信息。 目前，所有的EA通过一个共同的资源访问引擎。目标是每个顾问都有一个单独的资源来与引擎沟通。而引擎将能够为不同的EA重新连接资源。 Oleg Papkov 2019.01.14 16:52 #1462 我感到困惑的是，比方说，如果发动机运行时有第六个顾问，那么五个顾问将传送全部的工作包。其他五人应暂时被禁止传送工作信息。让他们只需 "听从电波"。 Реter Konow 2019.01.14 17:09 #1463 Oleg Papkov: 我感到困惑的是，比方说5个EA将传输全部的工作包，如果引擎运行时有第六个。其他五人应暂时被禁止传送工作信息。让他们只需 "听从电波"。我同意。这很有道理。 所以它们会正常工作，但不会向资源写入信息。只对参数内核的一个副本。而当连接时，将把参数内核写入资源，引擎将加载它。一旦连接，专家顾问将开始为引擎写消息到消息资源。 Oleg Papkov 2019.01.14 18:07 #1464 问题是关于连接。 该引擎向所有EA暴露了一个小的字符串地址。具有相同识别地址的EA中的内核被召回，标准的引擎顾问操作自动开始。当引擎切换到另一个EA时，引擎会将它正在工作的EA的内核切换到地址等待状态，就像那一刻的其他EA一样。此时，所有的EA都被断开了，引擎正在等待引擎需要的另一个EA的地址。 新EA的内核会做出反应，并进入标准运行状态。下一次，引擎继续发送终点，等待的状态没有改变。除了标准交换，专家顾问还必须分析一个流程，以检查工作线的末端是否出现在其中。在交换数据包的开头，必须有一个字符串，表明数据包是由引擎发给谁的。该内核收到控制数据包，并开始以指定的频率发送其状态的数据包。 其他的则等待他们通过每个EA的独特识别字符串来解决。切换时，引擎会向当前的EA发送一个寿命终止的字符串。EA停止发送任何东西，进入识别自己的识别字符串的状态，这同时也是与引擎交换的标准工作的开始。 Реter Konow 2019.01.14 19:55 #1465 Oleg Papkov:问题是关于连接。 该引擎向所有EA暴露了一个小的字符串地址。具有相同识别地址的EA中的内核被召回，标准的引擎顾问操作自动开始。当引擎切换到另一个EA时，引擎会将它正在工作的EA的内核切换到地址等待状态，就像那一刻的其他EA一样。此时，所有的EA都被断开了，引擎正在等待引擎需要的另一个EA的地址。 新EA的内核会做出反应，并进入标准运行状态。下一次，引擎继续发送终点，等待的状态没有改变。除了标准交换，专家顾问还必须分析一个流程，以检查工作线的末端是否出现在其中。在交换数据包的开头，必须有一个字符串，表明数据包是由引擎发给谁的。该内核收到控制数据包，并开始以指定的频率发送其状态的数据包。 其他的则等待他们通过每个EA的独特识别字符串来解决。在切换时，引擎会向当前的EA发送一个寿命终止的字符串。EA停止发送任何东西，进入识别自己的识别字符串的状态，这同时也是与引擎交换的标准工作的开始。资源方面则有些简单。你不需要一个地址，只需要一个资源名称。你有一个更复杂的模型。这更简单。 核心是一个简单的值数组。每个专家顾问将在其中写入其GUI元素的参数值。必要时，EA将把内核参数的副本保存到资源中，引擎将读取它并重新绘制GUI。 原则上，这是一个简单的任务，但有许多小的细微差别。例如，关于开始和停止与EA通信的信息。我们只需要考虑格式问题。 顺便说一句，我已经成功地加快了沟通速度，减少了缓慢的程度。然而，我还没有理解其中的原因。它发生在重绘过程中，但奇怪的是，重绘本身并不是制动的。但在与资源沟通时，重新绘制的速度就慢了。原因尚不清楚。 Oleg Papkov 2019.01.15 01:05 #1466 投入某种时间成本监测。要看它在哪里放慢了速度。以及如何绕过它。 也许我把它弄得有点复杂。我不知道它在你的发动机内是如何组织的。我只是在用逻辑。 Реter Konow 2019.01.15 06:19 #1467 Oleg Papkov:投入某种时间成本监测。要看它在哪里放慢了速度。以及如何绕过它。 也许我把它弄得有点复杂。我不知道它在你的发动机内是如何组织的。我只是在用逻辑。逻辑让你更接近重点，一般来说，你的理解是正确的。 今天，我将试图弄清刹车的原因。下面就很清楚了--重绘本身并没有放慢速度。写入和读取资源的速度也不慢。但我们一起得到了缓慢。 Oleg Papkov 2019.01.15 11:20 #1468 有监控，哪种操作能持续多长时间？它们必须按顺序进行。在EA中，它们，采取数据并将其发送到引擎的频率为，例如，30ms。当一个线程被发送到引擎时，它是否准备好接收？或者它是做什么的？ Реter Konow 2019.01.15 11:36 #1469 Oleg Papkov: 有监控，哪个操作需要多长时间？它们应按顺序进行。专家顾问执行它们，捕捉数据并以例如30毫秒的频率将它们发送到引擎。当一个线程被发送到引擎时，它是否准备好接收？或者它是做什么的？现在正在检查一切。 引擎以30ms的频率从EA读取消息资源，而EA则以相同的频率从引擎读取消息资源。在同一频率上，他们都向对方写信息（如果有什么可写的话）。所有这些都不会导致任何速度减慢。另外，重绘本身，并不引起制动。 然而，如果在引擎端有重绘和写/读资源的组合，就会出现速度下降。这方面的原因还不清楚。想明白了。 Oleg Papkov 2019.01.15 13:15 #1470 Реter Konow:现在正在检查一切。 引擎以30ms的频率从EA读取消息资源，而EA则以相同的频率从引擎读取消息资源。在同一频率上，他们都会给对方写信息（如果有什么要写的话）。所有这些都不会导致任何速度减慢。另外，重绘本身，并不引起制动。 然而，如果在引擎端有重绘和写/读资源的组合，就会出现速度下降。这方面的原因还不清楚。检查一下吧。也许是不匹配：EA和引擎，1-都互相发送，2-都接收，它们的OnTimer周期不同步。等待意外同步的时刻，才能正常工作。这可能是原因吗？ 1...140141142143144145146147148149150151152153154...184 新评论 原因: 取消 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
一般来说，这个问题几乎已经解决了。
我感到困惑的是，比方说5个EA将传输全部的工作包，如果引擎运行时有第六个。其他五人应暂时被禁止传送工作信息。让他们只需 "听从电波"。
我同意。这很有道理。
所以它们会正常工作，但不会向资源写入信息。只对参数内核的一个副本。而当连接时，将把参数内核写入资源，引擎将加载它。一旦连接，专家顾问将开始为引擎写消息到消息资源。
问题是关于连接。
该引擎向所有EA暴露了一个小的字符串地址。具有相同识别地址的EA中的内核被召回，标准的引擎顾问操作自动开始。当引擎切换到另一个EA时，引擎会将它正在工作的EA的内核切换到地址等待状态，就像那一刻的其他EA一样。此时，所有的EA都被断开了，引擎正在等待引擎需要的另一个EA的地址。
新EA的内核会做出反应，并进入标准运行状态。下一次，引擎继续发送终点，等待的状态没有改变。除了标准交换，专家顾问还必须分析一个流程，以检查工作线的末端是否出现在其中。在交换数据包的开头，必须有一个字符串，表明数据包是由引擎发给谁的。该内核收到控制数据包，并开始以指定的频率发送其状态的数据包。
其他的则等待他们通过每个EA的独特识别字符串来解决。切换时，引擎会向当前的EA发送一个寿命终止的字符串。EA停止发送任何东西，进入识别自己的识别字符串的状态，这同时也是与引擎交换的标准工作的开始。
问题是关于连接。
该引擎向所有EA暴露了一个小的字符串地址。具有相同识别地址的EA中的内核被召回，标准的引擎顾问操作自动开始。当引擎切换到另一个EA时，引擎会将它正在工作的EA的内核切换到地址等待状态，就像那一刻的其他EA一样。此时，所有的EA都被断开了，引擎正在等待引擎需要的另一个EA的地址。
新EA的内核会做出反应，并进入标准运行状态。下一次，引擎继续发送终点，等待的状态没有改变。除了标准交换，专家顾问还必须分析一个流程，以检查工作线的末端是否出现在其中。在交换数据包的开头，必须有一个字符串，表明数据包是由引擎发给谁的。该内核收到控制数据包，并开始以指定的频率发送其状态的数据包。
其他的则等待他们通过每个EA的独特识别字符串来解决。在切换时，引擎会向当前的EA发送一个寿命终止的字符串。EA停止发送任何东西，进入识别自己的识别字符串的状态，这同时也是与引擎交换的标准工作的开始。
资源方面则有些简单。你不需要一个地址，只需要一个资源名称。你有一个更复杂的模型。这更简单。
核心是一个简单的值数组。每个专家顾问将在其中写入其GUI元素的参数值。必要时，EA将把内核参数的副本保存到资源中，引擎将读取它并重新绘制GUI。
原则上，这是一个简单的任务，但有许多小的细微差别。例如，关于开始和停止与EA通信的信息。我们只需要考虑格式问题。
顺便说一句，我已经成功地加快了沟通速度，减少了缓慢的程度。然而，我还没有理解其中的原因。它发生在重绘过程中，但奇怪的是，重绘本身并不是制动的。但在与资源沟通时，重新绘制的速度就慢了。原因尚不清楚。
投入某种时间成本监测。要看它在哪里放慢了速度。以及如何绕过它。
也许我把它弄得有点复杂。我不知道它在你的发动机内是如何组织的。我只是在用逻辑。
投入某种时间成本监测。要看它在哪里放慢了速度。以及如何绕过它。
也许我把它弄得有点复杂。我不知道它在你的发动机内是如何组织的。我只是在用逻辑。
逻辑让你更接近重点，一般来说，你的理解是正确的。
今天，我将试图弄清刹车的原因。下面就很清楚了--重绘本身并没有放慢速度。写入和读取资源的速度也不慢。但我们一起得到了缓慢。
有监控，哪个操作需要多长时间？它们应按顺序进行。专家顾问执行它们，捕捉数据并以例如30毫秒的频率将它们发送到引擎。当一个线程被发送到引擎时，它是否准备好接收？或者它是做什么的？
现在正在检查一切。
引擎以30ms的频率从EA读取消息资源，而EA则以相同的频率从引擎读取消息资源。在同一频率上，他们都向对方写信息（如果有什么可写的话）。所有这些都不会导致任何速度减慢。另外，重绘本身，并不引起制动。
然而，如果在引擎端有重绘和写/读资源的组合，就会出现速度下降。这方面的原因还不清楚。想明白了。
现在正在检查一切。
引擎以30ms的频率从EA读取消息资源，而EA则以相同的频率从引擎读取消息资源。在同一频率上，他们都会给对方写信息（如果有什么要写的话）。所有这些都不会导致任何速度减慢。另外，重绘本身，并不引起制动。
然而，如果在引擎端有重绘和写/读资源的组合，就会出现速度下降。这方面的原因还不清楚。检查一下吧。
也许是不匹配：EA和引擎，1-都互相发送，2-都接收，它们的OnTimer周期不同步。等待意外同步的时刻，才能正常工作。这可能是原因吗？