Торговая деятельность в платформе связана с формированием и отсылкой рыночных и отложенных ордеров для исполнения брокером, а также с управлением текущими позициями путем их модификации или закрытия. Платформа позволяет удобно просматривать торговую историю на счете, настраивать оповещения о событиях на рынке и многое другое. Открытие позиций...
然而，它说的是关于绊倒宏的完全相同的事情。 然而，我们当然会检查它。
这个项目的发展仍有巨大的潜力，特别是在使用自己的资源改进语言方面，因为MQL中的许多东西还没有实现，许多东西工作得很糟糕（bug），而且据我所知，开发人员没有计划改进语言本身的任何东西。
为了处理宏，我必须在整个链条的开始部分实现额外的层--描述宏的语法，在源码中解析它们，并进行解释（为每个宏获得结果源/值）。这很复杂，而且该应用只对一些MQL程序员有要求，所以没有开发。
至于使用哈希值来识别产品的变化，我不认为这是一个解决方案（或者我不知道我们在谈论什么用例）。通常情况下，你需要在一些前文件生成一两年后才能了解其中的某个特定模块是什么版本以及它的来源。要做到这一点，你可能需要将构建过程与版本控制系统联系起来。哈希不是一个选项。
帮助我解决OnTradeTransaction() 的问题。下面描述的行为是否正常？我在测试器中检查了它--它是这样的：（ 在 "真实 "账户上呢？
OnTick()有一个循环，按顺序关闭头寸。
OnTradeTrancaction()计算未结头寸的数量。
专家顾问是这样做的：它首先将循环关闭到最后，然后转到OnTradeTransaction，以同样的顺序进行计算。
换句话说，它并不
а
也就是说，它是按顺序工作的，而不是并行的。
如果上述描述是正常的，那么事实证明，OnTradeTransaction()只能安全地用于只打开/关闭一个订单的专家顾问系统中。如果有一个网格或一个多符号网格（或多符号网格，这是在这里找到的:) )- 算法就会崩溃。
引自文件
从终端手动或通过OrderSend()/OrderSendAsync()函数发送的一个交易请求可以在交易服务器上产生几个连续的交易。此外，这些交易到达终端的顺序 ，所以我们不能把 我们的交易算法建立在等待一个又一个交易的到来。
因此，一切都将被计算出来，但不是按照预期的顺序。
你能解释一下为什么你决定在OnTradeTrancaction()中计算头寸的数量？如果没有正确地组织计算，那么我们就不能排除会有不必要的操作。毕竟，如果你在循环中关闭几个头寸，就没有必要在关闭每个头寸后重新计算所有的头寸。循环结束后数一次就够了。或者，在OnTradeTrancaction()中安排，当IN类型被设置时，数量增加1，当OUT类型被设置时，数量减少。而即使在这种情况下，如果没有完全关闭仓位，也必须考虑到这一点。
你能解释一下为什么你决定在OnTradeTrancaction()中计算头寸的数量吗？
如果你计算每一个刻度 - 它是资源密集型的，特别是在策略测试器中很明显。只有在交易事件中，即当未结头寸清单中的某些内容实际发生变化时，才进行计算，这不是更正确吗？有了OnTradeTransaction()，更容易控制用户对EA的干预。(有一些先例 :)
在这个机器人中，我正在测试关闭网格的可能性：损失+利润>X，然后关闭它们（通常在不同的符号上）。但是，失败发生了，因为即使它们已经关闭，测试人员也没有意识到这一点，并继续进行下一次迭代，错误地将现有的与已经关闭的 "配对"。也就是说，我不得不在每次关闭后增加一次重新计算。
我在重新计算时有一个复位的计数器，而且是先计算所有打开的计数器，而不是+1/-1。
引自文件
我同意，最初使用OnTradeTransaction() 太冒险了。 实际上，在请求不是异步的 情况下，我可能会拒绝它--只是从中产生问题。
对于多符号网格，异步是好的。这就是为什么我会选择第二个选项。
已经在往这个方向想了；)
***
在这个机器人中，我测试了根据计划关闭网格的可能性：损失+利润>X ，然后关闭两者（通常在不同的符号上）。
***
如果你知道你想准确地关闭这两个头寸，最好记住这些头寸的票据，并关闭它们，直到你关闭它们（注意：没有while和Sleep- 下达关闭命令，退出OnTick，检查是否有更多的头寸有这些票据 - 如果有，尝试再次关闭它们并退出OnTick）。
如果你知道你正好需要关闭这两个头寸，最好记住这些头寸的代码，并关闭它们，直到你关闭它们（注意：没有while和Sleep--下达关闭指令，退出OnTick，检查是否有更多带有这些代码的头寸--如果有，则再次尝试关闭并退出OnTick）。
这是一个有价值的想法。也许OnTick()与票据形成一个数组，并试图关闭它一次，而OnTimer()检查是否有更多的票据，如果有，就关闭。
两者之间可能有几分钟的时间间隔，所以让我们把任务传递给计时器有价值的想法。也许是这样吧：OnTick()生成一个包含票据的数组，并尝试关闭一次，而OnTimer()则检查它们是否仍然存在，如果存在则关闭。
嘀嗒声之间可能有几分钟的时间，所以让我们把任务传递给一个定时器我将放弃ALL while、Sleep和OnTimer的平仓 任务。我将做以下工作：发射订单平仓--退出OnTick，在下一个tick上，我将检查有需要的票据的头寸是否仍然存在--再次发射订单平仓，如此循环，通过进入/退出OnTick。
逻辑如下：平仓是第一要务，所以平仓循环是在OnTick的最开始。而闭合票据数组的形成可以位于Tick上的任何地方--甚至在最末端。
***
两者之间可能有几分钟的时间间隔，所以让我们把任务传递给计时器因此，我们无能为力--我们只得等待新的蜱虫。
OnTick()生成一个包含票据的数组，并尝试关闭它们一次，而OnTimer()检查它们是否仍然存在，如果存在则关闭。
另一个选择（对于现实世界--这是最好的）是在虚拟环境中运行EA（有一个完美的执行），在现实世界中只与虚拟环境同步。
所以你什么也做不了--只是等待下一次打勾。
例如，如果出现了网络故障，那么等待下一次勾选就是错过了关闭的机会。
例如，如果出现了网络故障，那么等待下一次勾选就是错过了一次成交的机会。
网络故障==断线？如果没有互联网，那么什么都无法关闭或打开 - 错过的机会是什么？
一般来说，如果交易系统对每一个喷嚏（连接失败或其他）都非常敏感--那么这样的交易系统就完蛋了。