Взаимодействие клиентского терминала и торгового сервера для проведения операций постановки ордеров производится посредством торговых запросов. Запрос представлен специальной предопределенной структурой MqlTradeRequest, которая содержит все поля, необходимые для заключения торговых сделок. Результат обработки запроса представлен структурой...
Глобальные переменные создаются путем размещения их объявлений вне описания какой-либо функции. Глобальные переменные определяются на том же уровне, что и функции, т. е. не локальны ни в каком блоке. Область видимости глобальных переменных - вся программа, глобальные переменные доступны из всех функций, определенных в программе...
不是我不想就这一话题进行交流，而是你们没有理解这一话题的本质。
你认为我不理解每种类型的延迟查询都需要自己的解决方案。所有请求都有自己的属性，不可能有通用的解决方案。针对订单的解决方案是一种，针对重复请求某些数据的解决方案是另一种。在前两篇文章中，我们正在研究订单的解决方案。下一篇文章也将讨论这个问题。我认为这篇文章太长了。
3 篇文章只解决订单的挂起请求，其中两篇没有完成任何....。虽然事实上（而不是形式上）挂单请求的解决方案非常简单。
你认为我不了解每种待处理查询都需要不同的解决方案。所有查询都有自己的属性，不可能有通用的解决方案。一种解决方案适用于订单，另一种适用于重复请求某些数据。在前两篇文章中，我们正在研究订单的解决方案。下一篇文章也将讨论这个问题。我认为这篇文章太长了。
3 篇文章只解决订单的挂起请求，其中两篇没有完成任何....。虽然事实上（而非形式上）解决挂单请求非常简单。
说 "不可能 "有点草率。
没错，这是不可能的。不同的查询对象有不同的属性。你不可能把所有属性都放在一个查询对象中。
我只是想知道，一个简单的任务怎么能用三篇文章解决一个半月。如果这种编程方法也算 "高效 "的话，那我真庆幸自己的编程方式与众不同。
不可能追踪 EA 对服务器的所有调用。
我之所以这样问，是因为解决重复发送失败订单的问题（很明显）不需要复杂的方法，只需简单地解决即可。
如果不使用库方法发送订单，那么所有交易逻辑都必须独立编写。程序库提供了不这样做的机会，但并不强迫您通过其功能完成所有工作。
在这种情况下，程序库无法管理不属于自己的交易功能。但它可以报告通过第三方功能发送的交易请求 成功的事实。
使用库的功能，可以对服务器返回的错误做出反应并进行适当处理。
您认为服务器返回代码的处理程序是什么？
没错，这是不可能的。不同的查询对象有不同的属性。不能在一个查询对象中插入所有属性。
我只是想知道，一个简单的任务怎么可能在一个半月内用三篇文章就解决了。如果这种编程方法被认为是 "高效 "的，那么我很高兴我的编程方法与众不同。
对象是待处理的交易 请求。有关任何交易请求的所有信息都存储在所有请求的单一结构 -MqlTradeRequest 中。
你是在耍我吗？
事实上，我描述了这个概念。一步一步地。在文章中（我自己写的文章，我检查了三四次是否有错误，我错过了一些错误）。我在文章中阐述概念的内容、逻辑和功能，告诉大家如何去做。与此同时，我会事先考虑各种方案，其中很大一部分会被扔进垃圾桶--也就是说，事实上，我写的代码要比文章中的代码多三到四倍。有时，我会根据不同的原则从头开始重新编写所有代码。然后，我在测试器和演示中测试每篇文章中描述的一切。然后我会忽略一些错误，并在下一篇文章中加以修正。
如果代码第一次就能正常工作，那就意味着其中埋藏了炸弹，希望将来会有大惊喜。
我很惊讶你在一个小时内就写完了所有东西。不检查、不测试，只要能动就行:)
我真的很想知道你认为这里的简单是什么。你为什么不想明白，这是程序库其他部分未来功能的一部分，而所有事先准备好的东西都应该 "在你的脑海中 "与尚未出现但计划中的东西联系起来？
我不会设定一个任务，做完一次就任其发展。我有一项不同的任务--思考如何将所有东西进一步相互联系起来。这需要时间和一定的方法。如果这对你来说很困难，那么......那就复杂了。
...
您认为服务器返回代码处理程序是什么？
我将向您展示一个简短而有效的解决方案。
1. 声明一个全局变量： 字符串 Del_req；
2.2. 编写 void Delayed_request() 函数。该函数将每秒从 OnTimer() 中调用一次（如果 Del_req != NULL）。
3.3. 在每个发送订单的交易函数中添加参数 int delayed_request_ID = 0。
4.每个交易请求都会返回一个服务器响应。如果 delayed_request = 0（不是重复调用Delayed_request() ），且服务器响应要求重复请求，则交易函数会将所有调用参数写入 Del_req 变量（通过两个分隔符--delayed_request_ID 和参数），并在行尾添加所需的尝试次数（例如 10 次）。
5.5. Delayed_request() 函数每秒检查一次 Del_req 字符串。如果字符串不是 NULL，函数会将其放入数组并循环查找调用的子字符串，找到后将其从整个字符串中提取出来，进行拆分，查看调用类型，并将参数与 delayed_request_ID 一起传递给所需的交易函数。接下来，它会查看调用计数器，并将其减一。如果计数器减一后为零，则会从 Del_req 字符串中删除整个呼叫子串。
6.6. 如果交易函数接收到带有 delayed_request_ID 的呼叫，且向服务器发出的请求成功，则从总 Del_req 字符串中删除呼叫子串（通过 delayed_request_ID 查找）。
所有这些都可以在一天内完成，而且不仅适用于交易请求，也适用于任何请求。
ZY，我不是在开玩笑，我只是对成熟程序员的简单解决方案的非显而易见性感到惊讶。
我会告诉你一个简短有效的解决方案。
1.声明一个全局变量： 字符串 Del_req；
2.编写 void Delayed_request() 函数。该函数将每秒从 OnTimer() 中调用一次。
3.为每个发送订单的交易函数添加一个参数 int delayed_request_ID = 0。
4.每个交易请求都会返回一个服务器响应。如果 delayed_request = 0（不是重复调用Delayed_request() ），且服务器响应要求重复请求，则交易函数会将所有调用参数写入 Del_req 变量（通过两个分隔符--delayed_request_ID 和参数），并在行尾添加所需的尝试次数（如 10 次）。
5.5. Delayed_request() 函数每秒检查一次 Del_req 字符串。如果字符串不是空值，函数会将其放入数组并循环查找调用，找到后将其从整个字符串中提取出来，分割开来，查看调用类型，并将参数与 delayed_request_ID 一起传递给所需的交易函数。接下来，它会查看调用计数器，并将其减一。如果计数器不为零，Del_req 会将调用字符串中的调用计数器改为小于 1 的值；如果计数器为零，Del_req 会从整个 Del_req 字符串中删除整个调用字符串。
6.6. 如果交易函数接收到带有 delayed_request_ID 的呼叫，且向服务器发出的请求成功，则会从 Del_req 字符串中删除呼叫子串（通过 delayed_request_ID 查找）。
所有这些都可以在一天内完成，而且不仅适用于交易请求，也适用于任何请求。
ZY，我不是在开玩笑，我只是对成熟程序员的简单解决方案的非显而易见性感到惊讶。
故意在方法中加入刹车？
提出的方法和正在做的方法有什么区别？除了你必须在处理字符串时使用昂贵的函数之外？概念上没有区别。这就是为什么--它将如其所愿。此外，正在进行的工作（你还不知道）将用于扩展处理延迟查询的功能。
在方法上有意识地踩刹车？
提出的方法和正在做的方法有什么区别？除了你必须通过昂贵的函数来处理字符串之外？没什么区别。这就是为什么--它将如其所愿。此外，正在进行的工作（你还不知道）将用于扩展处理延迟查询的功能。
你认为合适就去做吧。这是你的创造力。我表达了我的意见。
而且没有刹车。挂起请求仍然每秒发送一次。
不同的是，待处理请求不会变成成熟的对象，因此不会拖累大量代码。
随心所欲。这是你的艺术。我给出了我的意见。
而且没有刹车。无论如何，待处理的请求每秒都会发送一次。
为什么每秒发送一次？为了淹没交易服务器？
它的不同之处在于，待处理查询不会变成正式的对象，因此不会拖累大量代码。
而我只需要成熟的对象来实现我下一步要做的事情。但你还不知道，而且你还在试图提供无效的方法来解决任务的一小部分，以便进一步开展工作。而在这里，所有事情都是联系在一起的，总体概念也是一样的--未来计划的其他事情都取决于这一小部分。
无论如何，感谢您的意见--任何意见都是有用的、有意义的。
ZY，是的，写一段可工作、可扩展、可兼容的代码并不可怕，可怕的是为了下一个任务而不断重写以前不经意写的不完整的解决方案。