在贸易交易中的处理 - 页 6 12345678910 新评论 Ilya Rebenok 2019.02.09 08:14 #51 下午好。 没有人被任何人吓倒。 prostotrader:你没有switch(trans.type)。 嗯，当然，给定的情况是在switch(trans.type)。由于有另一个案例，我不想显示所有的代码，以免不必要的信息过多。 fxsaber ，谢谢你的榜样！"。 阿列克谢，这是完全一样的。我正在使用2个不同的机器人在净值模式下对同一个符号进行交易。你引用的那2个帖子是相互补充的。 从主要的变化触发器--onTradeTransaction 开始解决这个问题很有意思。 目前遇到的问题总数。 1.deal_add触发了，但没有摆出姿势。到目前为止没有任何想法。 2.deal_add被触发了，但订单在第三维。放一放，这几天似乎有帮助。该命令设法在1秒内进入历史。我没有高频交易机器人，也不使用市场订单，因此这个解决方案是合适的。 3.deal_add被触发了2次，即一个相同的deal_add被触发了2次。这可以通过检查以前的交易票据并与现在的票据进行比较来解决。 还有第1点，对它的解释。 昨天我设置了sell_limit，它起作用了，deal_add来了，但头寸没有出现，我们白白开了一个止损单。我开始看交易描述，看到交易类型是DEAL_TYPE_SELL，但订单类型是ORDER_TYPE_BUY。同时，订单票是我们的。这似乎不太符合逻辑。我决定在OnTradeTransaction中检查订单类型和交易类型是否应该相同，订单类型和交易类型应该相同。 我在演示版上启用了专家顾问，得到了另一个类似的交易，但这次的位置已经改变。但由于我们的检查，该止损单没有被执行。发生了什么事？ 2019.02.08 16:05:14 [INFO]: ( FrTrend_2_Si-3.19_33) TRADE_TRANSACTION_DEAL_ADD TRADE_TRANSACTION_DEAL_ADD Symbol: Si-3.19 Deal ticket: 12677775 Deal type: DEAL_TYPE_SELL Order ticket: 82675535 Order type: ORDER_TYPE_BUY Order state: ORDER_STATE_STARTED Order time type: ORDER_TIME_GTC Order expiration: 1970.01.01 00:00 Price: 66287 Price trigger: 0 Stop Loss: 0 Take Profit: 0 Volume: 1 Position: 82675534 Position by: 0 我马上告诉你，这就是进入终端的情况。没有我的编造。 JRandomTrader 2019.02.09 08:40 #52 Илья Ребенок:昨天我下了卖出限制，它被触发了，增加了交易，但没有出现头寸，我们白白开了止损单。我开始查看交易描述，看到交易类型是DEAL_TYPE_SELL，订单类型是ORDER_TYPE_BUY。同时，订单票是我们的。这似乎不太符合逻辑。我决定在deal_add交易的OnTradeTransaction中检查订单类型和交易类型是否一致。 但这里值得重新阅读"贸易交易结构"的帮助--就deal_add类型而言，要填写哪些字段。 而且不是从交易中获取订单属性（在交易中它们没有被填入，但零也对应于enum-type中的一些值），而是从订单本身获取，如果它此刻是可用的（而不是在从订单到历史的过渡过程中）。 fxsaber 2019.02.09 08:49 #53 这使 我们更容易分析事情的进展情况。 你可以补充说，在交易的同时，还可以记录头寸状态、当前订单和交易历史。然后就可以看到全貌了。 Ilya Rebenok 2019.02.09 08:49 #54 JRandomTrader:这就是"交易结构"帮助值得重读的地方--就deal_add类型而言，要填写哪些字段。 而且不是从交易中获取订单属性（在交易中没有填写，但零也对应于枚举类型中的一些值），而是从订单本身获取，如果它目前是可用的（而不是在从订单到历史的过渡过程中）。我同意，我意识到了这一点，但没有注意到。谢谢你提醒我。 然而，一个职位在一个案例中没有出现而在另一个案例中出现的问题仍然存在，而且不清楚。 JRandomTrader 2019.02.09 09:11 #55 Илья Ребенок: 然而，在一种情况下不出现而在另一种情况下出现的位置问题仍然存在，而且不清楚。 在deal_add交易中，该职位被开了罚单，但该职位之前并不存在，也没有显示出来？这一点必须得到解决。 Ilya Rebenok 2019.02.09 09:27 #56 JRandomTrader:在deal_add交易中，该职位被售票，但该职位之前并不存在，也没有显示出来？这需要加以整理。以前没有的位置 JRandomTrader 2019.02.09 09:37 #57 Илья Ребенок:以前没有的位置交易中是否有仓单？ Ilya Rebenok 2019.02.09 10:12 #58 JRandomTrader:交易中是否有仓单？在上面的帖子中，我必须做出一点误解。有一个头寸，然后被止损单 关闭。也就是说，头寸的数量变成了0。然后，交易被触发了，但头寸没有出现。 我想这就是你的意思。该交易包含了该职位的票据信息，但这个票据=前一个订单的票据。如果我理解正确的话，它应该是在织网模式下。Position: 82675534 JRandomTrader 2019.02.09 10:26 #59 Илья Ребенок:在上面的帖子中，我必须做出一点误解。有一个头寸，然后被止损单 关闭。也就是说，头寸的数量变成了0。然后，交易被触发了，但头寸没有出现。 我想这就是你的意思。该交易包含了该职位的票据信息，但这个票据=前一个订单的票据。因为一般来说，如果我理解正确的话，它应该是在网状模式下。如果该符号上的头寸（累计，所有机器人和手动交易一起）变成了0.0，下一笔交易将开出（DEAL_ENTRY_IN）一个新头寸，有一个新票（==订单票）。 事实上，在我看来，当净值化时，根本不需要看头寸--每个机器人都必须说明 "它的"--作为其订单的交易结果。 fxsaber 2019.02.09 10:43 #60 位置和DEAL_ENTRY标志的存在不应该以任何方式参与到逻辑中。 我们只需要看看新交易和当前订单的魔力和评论，作为自己/外国的标识。 工作代码显示。它是完全一样的。 试图通过OnTradeTransaction 来解决这个问题是一个糟糕的想法，因为有很多隐患。其中在一个特定的任务中，有时仍然可以绕过。但如果你稍微改变一下任务，在OnTradeTransaction-实现期间，整个逻辑就会被打破。 开发者已经创建了一个事件驱动的贸易模型，但他们没有提供一个工作实例。因为这完全是个混蛋，代码倾注在什么地方，它在多大程度上取决于每个例子。 因此，我建议看一下同步交易操作和OnTrade功能。那里的一切都更容易，而且逻辑非常灵活，可以进行修改。此外，它更可靠。 向Async+Transactions的过渡可与从高级语言到汇编程序的过渡相媲美。也就是说，它应该在TS创建的最后阶段完成，当它被充分研究，准备好真正的，最后是在不改变交易逻辑的情况下加快交易操作。 12345678910 新评论 原因: 取消 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
下午好。
没有人被任何人吓倒。
你没有switch(trans.type)。
嗯，当然，给定的情况是在switch(trans.type)。由于有另一个案例，我不想显示所有的代码，以免不必要的信息过多。
fxsaber ，谢谢你的榜样！"。
阿列克谢，这是完全一样的。我正在使用2个不同的机器人在净值模式下对同一个符号进行交易。你引用的那2个帖子是相互补充的。
从主要的变化触发器--onTradeTransaction 开始解决这个问题很有意思。
目前遇到的问题总数。
1.deal_add触发了，但没有摆出姿势。到目前为止没有任何想法。
2.deal_add被触发了，但订单在第三维。放一放，这几天似乎有帮助。该命令设法在1秒内进入历史。我没有高频交易机器人，也不使用市场订单，因此这个解决方案是合适的。
3.deal_add被触发了2次，即一个相同的deal_add被触发了2次。这可以通过检查以前的交易票据并与现在的票据进行比较来解决。
还有第1点，对它的解释。
昨天我设置了sell_limit，它起作用了，deal_add来了，但头寸没有出现，我们白白开了一个止损单。我开始看交易描述，看到交易类型是DEAL_TYPE_SELL，但订单类型是ORDER_TYPE_BUY。同时，订单票是我们的。这似乎不太符合逻辑。我决定在OnTradeTransaction中检查订单类型和交易类型是否应该相同，订单类型和交易类型应该相同。
我在演示版上启用了专家顾问，得到了另一个类似的交易，但这次的位置已经改变。但由于我们的检查，该止损单没有被执行。发生了什么事？
我马上告诉你，这就是进入终端的情况。没有我的编造。
昨天我下了卖出限制，它被触发了，增加了交易，但没有出现头寸，我们白白开了止损单。我开始查看交易描述，看到交易类型是DEAL_TYPE_SELL，订单类型是ORDER_TYPE_BUY。同时，订单票是我们的。这似乎不太符合逻辑。我决定在deal_add交易的OnTradeTransaction中检查订单类型和交易类型是否一致。
但这里值得重新阅读"贸易交易结构"的帮助--就deal_add类型而言，要填写哪些字段。
而且不是从交易中获取订单属性（在交易中它们没有被填入，但零也对应于enum-type中的一些值），而是从订单本身获取，如果它此刻是可用的（而不是在从订单到历史的过渡过程中）。
这使 我们更容易分析事情的进展情况。
你可以补充说，在交易的同时，还可以记录头寸状态、当前订单和交易历史。然后就可以看到全貌了。
这就是"交易结构"帮助值得重读的地方--就deal_add类型而言，要填写哪些字段。
而且不是从交易中获取订单属性（在交易中没有填写，但零也对应于枚举类型中的一些值），而是从订单本身获取，如果它目前是可用的（而不是在从订单到历史的过渡过程中）。
我同意，我意识到了这一点，但没有注意到。谢谢你提醒我。
然而，一个职位在一个案例中没有出现而在另一个案例中出现的问题仍然存在，而且不清楚。
Илья Ребенок:
然而，在一种情况下不出现而在另一种情况下出现的位置问题仍然存在，而且不清楚。
在deal_add交易中，该职位被开了罚单，但该职位之前并不存在，也没有显示出来？这一点必须得到解决。
在deal_add交易中，该职位被售票，但该职位之前并不存在，也没有显示出来？这需要加以整理。
以前没有的位置
以前没有的位置
交易中是否有仓单？
交易中是否有仓单？
在上面的帖子中，我必须做出一点误解。有一个头寸，然后被止损单 关闭。也就是说，头寸的数量变成了0。然后，交易被触发了，但头寸没有出现。
我想这就是你的意思。该交易包含了该职位的票据信息，但这个票据=前一个订单的票据。如果我理解正确的话，它应该是在织网模式下。
Position: 82675534在上面的帖子中，我必须做出一点误解。有一个头寸，然后被止损单 关闭。也就是说，头寸的数量变成了0。然后，交易被触发了，但头寸没有出现。
我想这就是你的意思。该交易包含了该职位的票据信息，但这个票据=前一个订单的票据。因为一般来说，如果我理解正确的话，它应该是在网状模式下。
如果该符号上的头寸（累计，所有机器人和手动交易一起）变成了0.0，下一笔交易将开出（DEAL_ENTRY_IN）一个新头寸，有一个新票（==订单票）。
事实上，在我看来，当净值化时，根本不需要看头寸--每个机器人都必须说明 "它的"--作为其订单的交易结果。
位置和DEAL_ENTRY标志的存在不应该以任何方式参与到逻辑中。
我们只需要看看新交易和当前订单的魔力和评论，作为自己/外国的标识。
工作代码显示。它是完全一样的。
试图通过OnTradeTransaction 来解决这个问题是一个糟糕的想法，因为有很多隐患。其中在一个特定的任务中，有时仍然可以绕过。但如果你稍微改变一下任务，在OnTradeTransaction-实现期间，整个逻辑就会被打破。
开发者已经创建了一个事件驱动的贸易模型，但他们没有提供一个工作实例。因为这完全是个混蛋，代码倾注在什么地方，它在多大程度上取决于每个例子。
因此，我建议看一下同步交易操作和OnTrade功能。那里的一切都更容易，而且逻辑非常灵活，可以进行修改。此外，它更可靠。
向Async+Transactions的过渡可与从高级语言到汇编程序的过渡相媲美。也就是说，它应该在TS创建的最后阶段完成，当它被充分研究，准备好真正的，最后是在不改变交易逻辑的情况下加快交易操作。