文章 "轻松快捷开发 MetaTrader 程序的函数库(第 二十七部分):操控交易请求 - 下挂单" - 页 2 12345 新评论 Artyom Trishkin 2019.12.15 20:50 #11 Реter Konow:将近 4 兆字节的代码,而且没有提供库模式和自定义方法...你是在为自己编写吗?从用户的角度看问题。在没有参考点的 情况下,他们是如何理解这一切的。 好的、自给自足的参考点就是文章本身。它们不仅有指导原则,而且还被嚼得很透--如果你懒得读的话。 该计划将在图书馆创建的末尾。以及快速访问图书馆所有功能的用户案例方法。 Artyom Trishkin 2019.12.15 21:08 #12 Реter Konow:特别是在这篇文章中,没有说明为什么决定在连接互联网后立即发送挂单,而不重新询问用户。文章还警告说,文章中介绍的挂单请求不能用于实际交易。也就是说,这只是概念测试,仅此而已。没有解释如何在重新连接互联网后设置订单,而无需询问用户。你真的需要几篇文章来测试挂单交易请求的简单机制吗?此外,再次轮询用户更简单、更正确,仅此而已。 我一眼就看出您没有写过交易函数,也不太明白我们在说什么。 我试着再告诉您一遍(上一篇文章中已经说过):交易服务器存在一些错误,需要延迟一段时间才能重新向服务器发送交易请求。 通常建议使用 Sleep() 来延迟。但这会停止程序的执行。因此,整个程序将等待交易方法内部的暂停完成,然后再重新向服务器发送交易请求。 这样好吗?在一般最简单的情况下,是可以的。 但智能交易系统可以是多币种的。在等待时间内,除了等待,它不会做其他任何事情。 这样好吗?我认为不是--EA 应该继续监控其所有工作符号的环境。这正是挂起请求所能提供的:当它从服务器接收到需要等待的错误时,它会创建一个挂起请求,其中包含所需的尝试次数和两次尝试之间所需的等待时间,然后继续开展业务。然后,交易类本身会及时向服务器发送必要的交易请求。同时,它将首先检查 "为交易请求分配的所有尝试的执行时间是否已过"。因此,"智能交易系统 "不会在一百五十小时后向服务器发送过时的订单。 如果您非常喜欢与程序交流,我提出的 "待处理交易请求 "允许用户设置何时发送交易指令的条件。设定好条件后,您就可以忙自己的事情了--一旦条件出现,请求就会被触发。这是创建智能交易系统交易逻辑的众多方法之一。当程序库可以为您的程序创建图形外壳时,创建交易逻辑的工具将变得非常容易--输入必要的值,指定请求类型和需要工作的时间,仅此而已....。 要解释和回答您的问题 "为什么需要这么做",首先要想到的就是这一点--一切都不是 "此时此地 "完成的,而是一砖一瓦、循序渐进地完成的。 Реter Konow 2019.12.16 15:01 #13 Artyom Trishkin:一看就知道你没有写过交易函数,也不知道自己在说什么。我试着再告诉你一遍(上一篇文章中已经说过):交易服务器的一些错误要求在重新向服务器发送交易请求之前延迟一些时间。 通常建议使用 Sleep() 来延迟。但这会停止程序的执行。因此,整个程序将等待交易方法内部的暂停完成,然后再向服务器发送交易请求。 这样好吗?在一般最简单的情况下,是可以的。 但智能交易系统可以是多币种的。在等待时间内,除了等待,它不会做其他任何事情。 这样好吗?我认为不是--EA 应该继续监控其所有工作符号的环境。这正是挂起请求所能提供的:当它从服务器接收到需要等待的错误时,它会创建一个挂起请求,其中包含所需的尝试次数和两次尝试之间所需的等待时间,然后继续开展业务。然后,交易类本身会及时向服务器发送必要的交易请求。同时,它将首先检查 "为交易请求分配的所有尝试的执行时间是否已过"。因此,"智能交易系统 "不会在一百五十小时后向服务器发送过时订单。如果您非常喜欢与程序交流,我提出的 "待处理交易请求 "允许用户设置何时发送交易指令的条件。设定好条件后,您就可以忙自己的事情了--一旦条件出现,请求就会被触发。这是创建智能交易系统交易逻辑的众多方法之一。当程序库可以为您的程序创建图形外壳时,创建交易逻辑的工具将变得非常容易--输入必要的值,指定请求的类型和需要工作的时间,仅此而已....。要解释和回答 "为什么需要这么做 "的问题,首先要想到的就是这一点--一切都不是 "此时此地 "完成的,而是一砖一瓦、循序渐进地完成的。 如果与服务器的连接中断,Expert Advisor 中的所有计算都会停止,因为计算的主要引擎是价格。没有互联网--没有跳动点--在多货币智能交易系统 中没有任何计算。您需要等待连接。恢复连接后,您需要询问发送失败订单的情况,在此之前,您可以继续等待连接,反正也没什么可做的。 Artyom Trishkin 2019.12.16 15:55 #14 Реter Konow: 如果与服务器的连接中断,Expert Advisor 中的所有计算都会停止,因为计算的主要引擎是价格。在多货币智能交易系统中,没有互联网--没有跳动点--就没有计算。您需要等待连接。恢复连接后,您需要询问发送失败订单的情况,在此之前,您可以继续等待连接,反正也没什么可做的。 Pyotr,连接失败并不是唯一需要在重复之前等待的错误。您只是为了测试而人为地制造了一个错误...库中不会有睡眠等待。 Реter Konow 2019.12.16 16:25 #15 Artyom Trishkin: 彼得, 连接失败并不是唯一需要等待后再重复的错误。 你只是抓住一个人为制造的错误不放,以进行测试.....。 库中不会有 "睡眠等待 "功能。 不可能跟踪 EA 对服务器的所有调用。 您只能通过库中的方法跟踪发送到服务器的交易订单。如果订单是通过您自己的函数发送的呢? 如果 EA 使用自己的方法与服务器通信,您将如何跟踪以及在连接失败/连接中断时如何处理? 因此才有了这个问题: 除了重新发送失败订单之外,您还能提出什么其他解决方案来解决 服务器通信问题? 我之所以这样问,是因为重新发送失败订单的解决方案(显然)不需要复杂的操作,只需简单地解决即可。 Реter Konow 2019.12.16 16:35 #16 Artyom Trishkin:...让我再说一遍(在上一篇文章中已经说过):由于交易服务器的一些错误,在向服务器重新发送交易请求之前需要一些延迟。 通常建议使用 Sleep() 来延迟。但这会停止程序的执行。因此,在向服务器发送重复请求之前,整个程序将等待交易方法内部的暂停完成。... 需要一份此类错误的具体列表和解释--库提供了哪些解决方案。 需要让用户应用程序库的功能,而不是他们自己的功能。 那么,这些错误是什么,您的解决方案一般是什么? Реter Konow 2019.12.16 16:52 #17 Реter Konow:...我之所以这么问,是因为解决重新发送失败订单的问题(显然)并不需要复杂的手续,只需简单地解决即可。 我看了上一篇文章。那里只涉及由于服务器不可用而发送订单失败的问题。解决方案的形式 比我想象的要复杂得多。但是,解决方案的本质 并没有变得更加复杂。 对于其他类型的重复请求,没有任何解决方案。 Artyom Trishkin 2019.12.16 17:41 #18 Реter Konow:我看了上一篇文章。它只谈到了由于服务器不可用而无法发送订单的问题。解决方案的形式 比我想象的要复杂得多。但解决方案的本质 并没有变得复杂。其他类型的重复请求没有解决方案。 请看:)你怎么会不知道,为了测试待处理查询的处理过程,我故意只模拟了一种可能的错误...在下一篇文章中,我简化了这种模拟--在终端中对自动交易按钮作出反应。错误列表在代码中。我不想为那些不懂的人再解释一遍。 Реter Konow 2019.12.16 17:54 #19 Artyom Trishkin: 您还进行了测试:) 您怎么会不知道,为了测试待处理请求的处理,我只专门模拟了一种可能的错误....。在下一篇文章中,我简化了这一模拟 - 在终端中对自动交易按钮作出反应。 错误列表就在代码中。我不想为那些不懂的人再解释一遍。 这不是答案。 您不想就这个问题进行交流,并说明库可以处理哪些待处理请求。 每个待处理请求(不是订单)都需要自己的解决方案--自己的魔法、自己的属性、自己的方法等等。 它在哪里? Artyom Trishkin 2019.12.16 18:02 #20 Реter Konow:这不是答案。你不想就这一主题进行交流,并说明图书馆可以处理哪些未决请求。每个待处理请求(不是订单)都需要自己的解决方案--自己的魔法、自己的属性、自己的方法等等。那么它在哪里呢? 不是我不想就这个话题进行交流,而是你们不了解这个话题的本质。在这三篇文章中,我们将测试一个新的交易概念--使用挂起请求进行交易。每篇文章都会逐渐添加新的对象--查询。此外,这只是在一个临时创建的类 上测试这个概念。在本主题的第四篇文章中,将创建此类对象的正式类。虽然数量不多,但足以满足该概念的所有需求。只是,为了不让我再重复一遍,请试着理解为什么需要它,它能给你带来什么可能性。我只举了几个例子--我马上想到的。 12345 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
将近 4 兆字节的代码,而且没有提供库模式和自定义方法...你是在为自己编写吗?
从用户的角度看问题。在没有参考点的 情况下,他们是如何理解这一切的。
好的、自给自足的参考点就是文章本身。它们不仅有指导原则,而且还被嚼得很透--如果你懒得读的话。
该计划将在图书馆创建的末尾。以及快速访问图书馆所有功能的用户案例方法。
特别是在这篇文章中,没有说明为什么决定在连接互联网后立即发送挂单,而不重新询问用户。
文章还警告说,文章中介绍的挂单请求不能用于实际交易。也就是说,这只是概念测试,仅此而已。
没有解释如何在重新连接互联网后设置订单,而无需询问用户。
你真的需要几篇文章来测试挂单交易请求的简单机制吗?此外,再次轮询用户更简单、更正确,仅此而已。
我一眼就看出您没有写过交易函数,也不太明白我们在说什么。
我试着再告诉您一遍(上一篇文章中已经说过):交易服务器存在一些错误,需要延迟一段时间才能重新向服务器发送交易请求。
通常建议使用 Sleep() 来延迟。但这会停止程序的执行。因此,整个程序将等待交易方法内部的暂停完成,然后再重新向服务器发送交易请求。
这样好吗?在一般最简单的情况下,是可以的。
但智能交易系统可以是多币种的。在等待时间内,除了等待,它不会做其他任何事情。
这样好吗?我认为不是--EA 应该继续监控其所有工作符号的环境。这正是挂起请求所能提供的:当它从服务器接收到需要等待的错误时,它会创建一个挂起请求,其中包含所需的尝试次数和两次尝试之间所需的等待时间,然后继续开展业务。然后,交易类本身会及时向服务器发送必要的交易请求。同时,它将首先检查 "为交易请求分配的所有尝试的执行时间是否已过"。因此,"智能交易系统 "不会在一百五十小时后向服务器发送过时的订单。
如果您非常喜欢与程序交流,我提出的 "待处理交易请求 "允许用户设置何时发送交易指令的条件。设定好条件后,您就可以忙自己的事情了--一旦条件出现,请求就会被触发。这是创建智能交易系统交易逻辑的众多方法之一。当程序库可以为您的程序创建图形外壳时,创建交易逻辑的工具将变得非常容易--输入必要的值,指定请求类型和需要工作的时间,仅此而已....。
要解释和回答您的问题 "为什么需要这么做",首先要想到的就是这一点--一切都不是 "此时此地 "完成的,而是一砖一瓦、循序渐进地完成的。
一看就知道你没有写过交易函数,也不知道自己在说什么。
我试着再告诉你一遍(上一篇文章中已经说过):交易服务器的一些错误要求在重新向服务器发送交易请求之前延迟一些时间。
通常建议使用 Sleep() 来延迟。但这会停止程序的执行。因此,整个程序将等待交易方法内部的暂停完成,然后再向服务器发送交易请求。
这样好吗?在一般最简单的情况下,是可以的。
但智能交易系统可以是多币种的。在等待时间内,除了等待,它不会做其他任何事情。
这样好吗?我认为不是--EA 应该继续监控其所有工作符号的环境。这正是挂起请求所能提供的:当它从服务器接收到需要等待的错误时,它会创建一个挂起请求,其中包含所需的尝试次数和两次尝试之间所需的等待时间,然后继续开展业务。然后,交易类本身会及时向服务器发送必要的交易请求。同时,它将首先检查 "为交易请求分配的所有尝试的执行时间是否已过"。因此,"智能交易系统 "不会在一百五十小时后向服务器发送过时订单。
如果您非常喜欢与程序交流,我提出的 "待处理交易请求 "允许用户设置何时发送交易指令的条件。设定好条件后,您就可以忙自己的事情了--一旦条件出现,请求就会被触发。这是创建智能交易系统交易逻辑的众多方法之一。当程序库可以为您的程序创建图形外壳时,创建交易逻辑的工具将变得非常容易--输入必要的值,指定请求的类型和需要工作的时间,仅此而已....。
要解释和回答 "为什么需要这么做 "的问题,首先要想到的就是这一点--一切都不是 "此时此地 "完成的,而是一砖一瓦、循序渐进地完成的。
如果与服务器的连接中断,Expert Advisor 中的所有计算都会停止,因为计算的主要引擎是价格。
彼得, 连接失败并不是唯一需要等待后再重复的错误。 你只是抓住一个人为制造的错误不放,以进行测试.....。
不可能跟踪 EA 对服务器的所有调用。
我之所以这样问,是因为重新发送失败订单的解决方案(显然)不需要复杂的操作,只需简单地解决即可。
...
让我再说一遍(在上一篇文章中已经说过):由于交易服务器的一些错误,在向服务器重新发送交易请求之前需要一些延迟。
通常建议使用 Sleep() 来延迟。但这会停止程序的执行。因此,在向服务器发送重复请求之前,整个程序将等待交易方法内部的暂停完成。
...
需要一份此类错误的具体列表和解释--库提供了哪些解决方案。
需要让用户应用程序库的功能,而不是他们自己的功能。
那么,这些错误是什么,您的解决方案一般是什么?
...
我之所以这么问,是因为解决重新发送失败订单的问题(显然)并不需要复杂的手续,只需简单地解决即可。
我看了上一篇文章。那里只涉及由于服务器不可用而发送订单失败的问题。解决方案的形式 比我想象的要复杂得多。但是,解决方案的本质 并没有变得更加复杂。
对于其他类型的重复请求,没有任何解决方案。
我看了上一篇文章。它只谈到了由于服务器不可用而无法发送订单的问题。解决方案的形式 比我想象的要复杂得多。但解决方案的本质 并没有变得复杂。
其他类型的重复请求没有解决方案。
您还进行了测试:)
这不是答案。
您不想就这个问题进行交流,并说明库可以处理哪些待处理请求。
每个待处理请求(不是订单)都需要自己的解决方案--自己的魔法、自己的属性、自己的方法等等。 它在哪里?
这不是答案。
你不想就这一主题进行交流,并说明图书馆可以处理哪些未决请求。
每个待处理请求(不是订单)都需要自己的解决方案--自己的魔法、自己的属性、自己的方法等等。那么它在哪里呢?