初学者的问题 MQL5 MT5 MetaTrader 5 - 页 643 1...636637638639640641642643644645646647648649650...1503 新评论 [删除] 2016.10.14 07:19 #6421 Alexey Viktorov:在名单上不是最后一个，但在时间上是 "最年轻的"。虽然我也是一样不顾一切。问题是关于修改的，我在写近...而如果你简单地修改它，订单列表中就不会有漏洞......你只是可能需要添加变量并为 它们赋值，而且必须检查参数以避免错误#1。嗯，米拉可以自己做。阿尔乔姆-特里什金。你怎么能确定 不会出现排序依赖，而且你根本不会错过错误的顺序？再次，为了可靠地 找到最后一个订单，需要通过 其 开盘时间 来识别，而不是通过其在列表中的位置。据我所知，列表中的订单只是从最早的（OrdersTotal()-1）到最新的（0）排列。如果情况不是这样（名单不是按时间排序的），你有证据，请提供。如果你是说在使用函数OrdersTotal()请求历史记录的时刻，另一个EA下了一个订单，那么它要么被跳过（在任何情况下，因为它没有时间出现在历史订单中），要么它也会成为订单列表中最新的。当然，我们可以强烈地自我保证，将所有订单的开仓时间从total-1比较到0，但当我们有大量的订单和交易符号时，这很难成为一个最佳解决方案。 Artyom Trishkin 2016.10.14 07:30 #6422 Alexey Kozitsyn:据我所知，列表中的订单只是从最早的（OrdersTotal()-1）到最新的（0）进行排序。如果情况不是这样（名单不是按时间排序的），你有证据，请提供。如果你是说在使用函数OrdersTotal()请求历史记录的时刻，另一个EA下了一个订单，那么它要么被跳过（在任何情况下，因为它没有时间出现在历史订单中），要么它也会成为订单列表中最新的。当然，我们可以强烈地自我保证，将所有订单的开仓时间从total-1比较到0，但当我们有大量的订单和交易符号时，这很难成为一个最佳解决方案。天啊...向他们证明... 我猜你不太记得很久以前在mql4.com上讨论过这种情况。这时我们得出的结论是，最好按时间搜索一个订单，以明确地确定其开/关时间。我已经厌倦了重复说对分类有依赖性。然后我们让它不再依赖排序。人们放松了警惕，开始按照你的建议去做。然后咣当一声......又有了对分类的依赖。人们嚎叫着--机器人发疯了。然后分类依赖性又消失了。如果你有一个愿望，希望所谓的优化有一天再次落入压迫之下，那么就按照你现在的方式去做。但不要向其他人建议这种解决方案。或者，在提供时，警告他们有可能因为搜索必要的顺序失败而永远失去金钱，这（搜索）取决于列表中的符号排序，而这又不取决于你和你的算法。相反--你的算法取决于其他人......不要告诉他们，经销商可以用开/关门的时间作弊，那是另一个问题。好运。 [删除] 2016.10.14 07:58 #6423 Artyom Trishkin:天啊...他们想要的证明... 显然，你不太记得很久以前在mql4.com上讨论过这种情况。这时你得出的结论是，最好按时间搜索一个订单，以毫不含糊地确定其开放/关闭时间。我已经厌倦了重复说对分类有依赖性。然后我们让它不再依赖排序。人们放松了警惕，开始按照你的建议去做。然后咣当一声......又有了对分类的依赖。人们嚎叫着--机器人发疯了。然后分类依赖性又消失了。如果你有一个愿望，希望所谓的优化有一天再次落入压迫之下，那么就按照你现在的方式去做。但不要向其他人建议这种解决方案。或者，在提供时，警告他们有可能因为搜索必要的顺序失败而永远失去金钱，这（搜索）取决于列表中的符号排序，而这又不取决于你和你的算法。相反--你的算法取决于其他人......不要告诉我经销商可以在开/关机时间上作弊--那是另一个问题。好运。是的，我不记得有这样的讨论，我不经常看四人小组的论坛。也许，在很久以前，就有这样的事情。但是，如果你建立在 "曾经 "的一切之上，任何资源都是不够的。如果你为了所谓的优化而有一个愿望，希望有一天再次落在十字路口，那么就照做吧。但不要向其他人建议这种解决方案。或者，在提供时，警告他们有可能因为搜索必要的顺序失败而永远失去金钱，这（搜索）取决于列表中的符号排序，而这又不取决于你和你的算法。相反--你的算法完全取决于别人......正如你所说的，有可能以其他一些方式 "被夹在十字路口"。如果你需要快速确定最后一个订单，及时搜索所有订单是不合理的。 每个人都应该自己决定是否接受我的方法。最好的解决办法是打开许多订单，看看现在的排序是如何进行的。也祝你好运。 Aleksey Vyazmikin 2016.10.14 08:02 #6424 Artyom Trishkin:你确定你已经展示了一个可靠的方法来错过列表中的最后一个位置吗？如果你实事求是地进行交易，你不担心排序会突然变得上瘾吗？不过，IMHO，我们在这里需要两个循环--在第一个循环中，我们按开盘时间 寻找最新鲜的位置，在第二个循环中，我们修改所有的位置，除了在第一个循环中找到票的那个。不，不确定，但在逻辑上是正确的。阅读了以下关于MQs的阴险性的文章--焦虑已经产生了。谢谢你的提醒。 Artyom Trishkin 2016.10.14 08:08 #6425 Alexey Kozitsyn:每当你需要快速识别最后一个订单时，及时翻阅它们并不是一个好主意，我已经说过了原因。 为什么我们必须每次都要经历这些？这正是非理性的表现。我们可以对市场头寸和已关闭的订单进行一次搜索，并将最后两个订单的所有必要数据填入结构的所有字段--开仓和平仓。并使用在此勾选期间获得的数据。在这个tick上改变它们之后，你将在下一个tick上得到两个结构的新数据和新字段。在我看来--这是可靠性和速度之间的正常平衡。这就是优化的意义所在。而你所谓的优化，IMHO，是一个斧头的工作;) [删除] 2016.10.14 08:18 #6426 Artyom Trishkin:为什么每次都要复习呢？这正是不理性的地方。你可以在每一个刻度线上搜索一次市场头寸和已关闭的订单，并在结构的所有字段中填入最后两个订单的所有必要数据--打开和关闭。并使用该勾选的数据。在这个勾里改变它们之后，你将在下一个勾里得到两个结构的新数据和新字段。在我看来--这是可靠性和速度之间的正常平衡。这就是优化的意义所在。而你所谓的优化，IMHO，是一个斧头的工作;)你是在谈细节，没有人提到关于每一次的事情。我和你一样，赞成理性，我们只是对它有不同的看法。 Artyom Trishkin 2016.10.14 08:25 #6427 Alexey Kozitsyn:你正在进入细微的差别，根本没有人在谈论每一次的问题。我和你一样，都赞成理性，只是你我对理性的看法不同而已。你自己的话。无论在哪里，你需要快速确定最后一个订单，及时查看所有的订单是不合理的，我认为...在这种情况下，"无处不在 "不是 "每一次 "的同义词？这就是为什么我说 "每打一次勾就过一次"，用正确的数据填入结构的字段，并在你需要获得最后一个订单的数据的地方使用它，而不是每次都要到处去找它。也许我理解错了？但你引用的表述，IMHO，排除了理解上的模糊性。 [删除] 2016.10.14 08:40 #6428 Artyom Trishkin:你自己的话。在这种情况下，"无处不在 "不是 "每一次 "的同义词？这就是我回答的原因--就是每打一次勾，用正确的数据填入结构的字段，并在你需要获得最后一个订单数据的地方使用它们，而不是每次都去看它们。也许我误解了？但你引用的表述，IMHO，排除了理解上的模糊性。你没有考虑到程序中可能有暂停/简单的长时间计算，之后必须更新交易环境。拖动一个订单数组并不总是很方便，而全局数组也不总是一个好的解决方案。总之，正如我所说，没有人劝阻你，但在有些情况下，你的选择会不那么可取（多货币/多订单系统）。而且，我认为没有必要保证MQ会再次改变排序顺序（鉴于它在mql4和mql5中是一样的）。 Artyom Trishkin 2016.10.14 09:11 #6429 Alexey Kozitsyn:你没有考虑到程序中可能有暂停/只是长时间的计算，之后你需要更新交易环境。在你身后拖动一个数组并不总是很方便，全局数组也不总是一个好的解决方案。总之，正如我所说，没有人劝阻你，但在有些情况下，你的选择会不那么可取（多货币/多订单系统）。而且要保证MQ会再次改变排序顺序（鉴于在mql4中是这样，在mql5中也是这样），我认为没有必要。一个能让你轻松毫不费力地拥有任何角色和任何魔术师的数据的类，在很久以前就已经做了。而且不需要携带任何东西，特别是整个阵列，而只需要两个订单--最后一个开放的和最后一个关闭的。每次，经过长时间的计算或等待，你必须重新填写结构字段，顺便说一下，你必须这样做，否则你就不更新你的环境？好的。这是一个没有问题的问题...用你的方式来做。不要担心可靠性--忘记它... [删除] 2016.10.14 10:23 #6430 Artyom Trishkin:早就有了一个类，可以让你轻松而不费力地拥有任何符号和任何魔术师的数据。而且不需要拖动任何东西，特别是整个数组，只需要拖动两个订单--最后打开和最后关闭。每次，经过长时间的计算或等待，你都要重新填写结构字段，顺便说一下，你必须这样做，否则你就不更新环境？好的。这不是什么大问题...用你的方式来做。不要担心可靠性--忘记它... 而且我确实更新了环境，只是你的搜索方法会花费更多的时间，仅此而已，关于可靠性的问题，这一点值得商榷。 1...636637638639640641642643644645646647648649650...1503 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
在名单上不是最后一个，但在时间上是 "最年轻的"。
虽然我也是一样不顾一切。问题是关于修改的，我在写近...而如果你简单地修改它，订单列表中就不会有漏洞......你只是可能需要添加变量并为 它们赋值，而且必须检查参数以避免错误#1。嗯，米拉可以自己做。
你怎么能确定 不会出现排序依赖，而且你根本不会错过错误的顺序？
再次，为了可靠地 找到最后一个订单，需要通过 其 开盘时间 来识别，而不是通过其在列表中的位置。
据我所知，列表中的订单只是从最早的（OrdersTotal()-1）到最新的（0）排列。如果情况不是这样（名单不是按时间排序的），你有证据，请提供。
如果你是说在使用函数OrdersTotal()请求历史记录的时刻，另一个EA下了一个订单，那么它要么被跳过（在任何情况下，因为它没有时间出现在历史订单中），要么它也会成为订单列表中最新的。
当然，我们可以强烈地自我保证，将所有订单的开仓时间从total-1比较到0，但当我们有大量的订单和交易符号时，这很难成为一个最佳解决方案。
据我所知，列表中的订单只是从最早的（OrdersTotal()-1）到最新的（0）进行排序。如果情况不是这样（名单不是按时间排序的），你有证据，请提供。
如果你是说在使用函数OrdersTotal()请求历史记录的时刻，另一个EA下了一个订单，那么它要么被跳过（在任何情况下，因为它没有时间出现在历史订单中），要么它也会成为订单列表中最新的。
当然，我们可以强烈地自我保证，将所有订单的开仓时间从total-1比较到0，但当我们有大量的订单和交易符号时，这很难成为一个最佳解决方案。
天啊...向他们证明...
我猜你不太记得很久以前在mql4.com上讨论过这种情况。这时我们得出的结论是，最好按时间搜索一个订单，以明确地确定其开/关时间。我已经厌倦了重复说对分类有依赖性。然后我们让它不再依赖排序。人们放松了警惕，开始按照你的建议去做。然后咣当一声......又有了对分类的依赖。人们嚎叫着--机器人发疯了。然后分类依赖性又消失了。
如果你有一个愿望，希望所谓的优化有一天再次落入压迫之下，那么就按照你现在的方式去做。但不要向其他人建议这种解决方案。或者，在提供时，警告他们有可能因为搜索必要的顺序失败而永远失去金钱，这（搜索）取决于列表中的符号排序，而这又不取决于你和你的算法。相反--你的算法取决于其他人......
不要告诉他们，经销商可以用开/关门的时间作弊，那是另一个问题。
好运。
天啊...他们想要的证明...
显然，你不太记得很久以前在mql4.com上讨论过这种情况。这时你得出的结论是，最好按时间搜索一个订单，以毫不含糊地确定其开放/关闭时间。我已经厌倦了重复说对分类有依赖性。然后我们让它不再依赖排序。人们放松了警惕，开始按照你的建议去做。然后咣当一声......又有了对分类的依赖。人们嚎叫着--机器人发疯了。然后分类依赖性又消失了。
如果你有一个愿望，希望所谓的优化有一天再次落入压迫之下，那么就按照你现在的方式去做。但不要向其他人建议这种解决方案。或者，在提供时，警告他们有可能因为搜索必要的顺序失败而永远失去金钱，这（搜索）取决于列表中的符号排序，而这又不取决于你和你的算法。相反--你的算法取决于其他人......
不要告诉我经销商可以在开/关机时间上作弊--那是另一个问题。
好运。
是的，我不记得有这样的讨论，我不经常看四人小组的论坛。也许，在很久以前，就有这样的事情。但是，如果你建立在 "曾经 "的一切之上，任何资源都是不够的。
如果你为了所谓的优化而有一个愿望，希望有一天再次落在十字路口，那么就照做吧。但不要向其他人建议这种解决方案。或者，在提供时，警告他们有可能因为搜索必要的顺序失败而永远失去金钱，这（搜索）取决于列表中的符号排序，而这又不取决于你和你的算法。相反--你的算法完全取决于别人......
正如你所说的，有可能以其他一些方式 "被夹在十字路口"。如果你需要快速确定最后一个订单，及时搜索所有订单是不合理的。
每个人都应该自己决定是否接受我的方法。最好的解决办法是打开许多订单，看看现在的排序是如何进行的。
也祝你好运。
你确定你已经展示了一个可靠的方法来错过列表中的最后一个位置吗？
如果你实事求是地进行交易，你不担心排序会突然变得上瘾吗？
不过，IMHO，我们在这里需要两个循环--在第一个循环中，我们按开盘时间 寻找最新鲜的位置，在第二个循环中，我们修改所有的位置，除了在第一个循环中找到票的那个。
不，不确定，但在逻辑上是正确的。
阅读了以下关于MQs的阴险性的文章--焦虑已经产生了。谢谢你的提醒。
每当你需要快速识别最后一个订单时，及时翻阅它们并不是一个好主意，我已经说过了原因。
为什么我们必须每次都要经历这些？这正是非理性的表现。
我们可以对市场头寸和已关闭的订单进行一次搜索，并将最后两个订单的所有必要数据填入结构的所有字段--开仓和平仓。
并使用在此勾选期间获得的数据。在这个tick上改变它们之后，你将在下一个tick上得到两个结构的新数据和新字段。在我看来--这是可靠性和速度之间的正常平衡。这就是优化的意义所在。而你所谓的优化，IMHO，是一个斧头的工作;)
为什么每次都要复习呢？这正是不理性的地方。
你可以在每一个刻度线上搜索一次市场头寸和已关闭的订单，并在结构的所有字段中填入最后两个订单的所有必要数据--打开和关闭。
并使用该勾选的数据。在这个勾里改变它们之后，你将在下一个勾里得到两个结构的新数据和新字段。在我看来--这是可靠性和速度之间的正常平衡。这就是优化的意义所在。而你所谓的优化，IMHO，是一个斧头的工作;)
你是在谈细节，没有人提到关于每一次的事情。我和你一样，赞成理性，我们只是对它有不同的看法。
你正在进入细微的差别，根本没有人在谈论每一次的问题。我和你一样，都赞成理性，只是你我对理性的看法不同而已。
你自己的话。
无论在哪里，你需要快速确定最后一个订单，及时查看所有的订单是不合理的，我认为...
在这种情况下，"无处不在 "不是 "每一次 "的同义词？
这就是为什么我说 "每打一次勾就过一次"，用正确的数据填入结构的字段，并在你需要获得最后一个订单的数据的地方使用它，而不是每次都要到处去找它。
也许我理解错了？但你引用的表述，IMHO，排除了理解上的模糊性。
你自己的话。
在这种情况下，"无处不在 "不是 "每一次 "的同义词？
这就是我回答的原因--就是每打一次勾，用正确的数据填入结构的字段，并在你需要获得最后一个订单数据的地方使用它们，而不是每次都去看它们。
也许我误解了？但你引用的表述，IMHO，排除了理解上的模糊性。
你没有考虑到程序中可能有暂停/简单的长时间计算，之后必须更新交易环境。拖动一个订单数组并不总是很方便，而全局数组也不总是一个好的解决方案。
总之，正如我所说，没有人劝阻你，但在有些情况下，你的选择会不那么可取（多货币/多订单系统）。而且，我认为没有必要保证MQ会再次改变排序顺序（鉴于它在mql4和mql5中是一样的）。
你没有考虑到程序中可能有暂停/只是长时间的计算，之后你需要更新交易环境。在你身后拖动一个数组并不总是很方便，全局数组也不总是一个好的解决方案。
总之，正如我所说，没有人劝阻你，但在有些情况下，你的选择会不那么可取（多货币/多订单系统）。而且要保证MQ会再次改变排序顺序（鉴于在mql4中是这样，在mql5中也是这样），我认为没有必要。
一个能让你轻松毫不费力地拥有任何角色和任何魔术师的数据的类，在很久以前就已经做了。而且不需要携带任何东西，特别是整个阵列，而只需要两个订单--最后一个开放的和最后一个关闭的。每次，经过长时间的计算或等待，你必须重新填写结构字段，顺便说一下，你必须这样做，否则你就不更新你的环境？
好的。这是一个没有问题的问题...用你的方式来做。不要担心可靠性--忘记它...
早就有了一个类，可以让你轻松而不费力地拥有任何符号和任何魔术师的数据。而且不需要拖动任何东西，特别是整个数组，只需要拖动两个订单--最后打开和最后关闭。每次，经过长时间的计算或等待，你都要重新填写结构字段，顺便说一下，你必须这样做，否则你就不更新环境？
好的。这不是什么大问题...用你的方式来做。不要担心可靠性--忘记它...