Кроме того, транзакции могут потеряться при доставке от сервера к терминалу. Что касается этой фразы.
Судя по всему - она осталась из документации к одной из начальных версий терминала с асинхронной торговли. В ближайшее время уберём. Виновные будут расстреляны.
暂停多少秒？1秒2，也许10？
2016.12.14 22:01:41.371 Trades 'xxxxx': cancel order #49932961 buy limit 1.00 CHMF-6.17 at 92501 placed for execution in 64873.549 ms
Кроме того, транзакции могут потеряться при доставке от сервера к терминалу. Что касается этой фразы.
Судя по всему - она осталась из документации к одной из начальных версий терминала с асинхронной торговли. В ближайшее время уберём. Виновные будут расстреляны.
我们应该停顿多长时间？1秒2，也许10？
2016.12.14 22:01:41.371 Trades 'xxxxx': cancel order #49932961 buy limit 1.00 CHMF-6.17 at 92501 placed for execution in 64873.549 ms
关于暂停的问题，你的建议是正确的。论坛上已经有一个话题说，在发送订单后停顿几毫秒往往就足以继续工作的位置。如果可以的话，你最好不要依赖OnTradeTransaction()。
而一般来说，为了更加可靠，尽量在订单发送后的下一个tick上检查仓位的可用性。如果有一个位置，不要发送更多的订单。
OnTradeTransaction()，如果可能的话，不要依赖它。
我想知道为什么？
1.并不确定它是否会到来。
2.之前在测试器中表现不佳。现在不知道了。
已添加。
3.一些订单或交易参数（记不清楚了），如枚举可以有 "默认值"，但不是。也就是说，MQ做的不是WRONG_VALUE，而是比如说ORDER_TYPE_BUY。可能会产生误导。
关于暂停的问题，你的建议是正确的。论坛上已经有一个话题说，在发送订单后停顿几毫秒往往就足以继续工作的位置。如果可以的话，你最好不要依赖OnTradeTransaction()。
而一般来说，为了更加可靠，尽量在订单发送后的下一个tick上检查仓位的可用性。如果有一个位置，不要发送更多的订单。
这就是额外的开盘可能溜走的地方....，部分地解决了这个问题，如下所示，如果订单被接受，我增加Int变量，增加后开盘的条件略有不同，所以新的开盘不会发生，但是....，如果订单不被接受，变量不会增加，这里是棘手的部分...我没有正确地确定状态，额外的订单就来了。
1.并不确定它是否会到来。
2.之前在测试器中表现不佳。现在不知道了。
你可能没有看到开发者的消息，现在，OnTradeTransaction() 是有保证的。
Что касается этой фразы.
Судя по всему - она осталась из документации к одной из начальных версий терминала с асинхронной торговли. В ближайшее время уберём. Виновные будут расстреляны.
暂停多少秒？1秒2，也许10？
添加
不要忘了，你是在与客户-服务器（请求-响应）应用一起工作。
你可能还没有看到开发者的消息，现在，OnTradeTransaction() 是有保证的。
Что касается этой фразы.
Судя по всему - она осталась из документации к одной из начальных версий терминала с асинхронной торговли. В ближайшее время уберём. Виновные будут расстреляны.
我们应该停顿多长时间？1秒2，也许10？
是的，你是对的，没有看到这句话，尸体也没有看到 :)
关于暂停--你给出了一个相当奇特的案例，然而，当然，这是有可能的。我指的是使用流动工具、当前合同以及在发送订单后立即在当前点上工作的情况。在绝大多数情况下，几毫秒的时间就足够了。当然，在暂停之后，有必要检查该位置的存在，以便进一步与之合作。
原则上我是这样做的，但在Forts中，订单往往被成功接受......但在下一个tick上，还没有位置......。
这就是额外的开口可能滑落的地方....，这样部分地解决了问题，如果订单被接受，我就增加Int变量，增加之后，开口的条件略有不同，所以没有新的开口，但是....，如果订单不被接受，变量不会增加，但是这里有一个技巧...我误判了状态，额外的订单开始出现。
是的，你是对的，我没有看到这句话，那些尸体也没有看到：）。
关于暂停--你引用了一个相当奇特的案例，然而，当然，这是有可能的。我指的是与流动性工具、当前合约一起工作的情况，以及在订单发送后在当前点上工作的情况。在绝大多数情况下，几毫秒的时间就足够了。当然，在暂停之后，有必要检查该位置的存在，以便进一步与之合作。
阿列克谢！
相当于一个流动的仪器 :)
这不是关于工具（流动性），而是关于延迟，这可能发生在任何工具上。
我一直积极使用EA进行交易，至今已有近4年。
在我的EA中没有任何停顿（除了在INDICATORS中等待从服务器下载数据时的停顿）。
如果你暂停了，这肯定是你的EA没有做对的迹象 :(
阿列克谢！
我一直积极使用EA进行交易，至今已有近4年。
我的任何EA都没有任何停顿（除了在INDICATORS中等待从服务器下载数据的停顿）。
如果你进入了暂停状态，这是一个真实的信号，说明你的EA的算法创建有误 :(
迈克尔，如果你没有看到或做过某件事，这并不意味着它不可能或没有必要。
我完全同意你的观点!
每个人都按照自己的意愿或能力去做。