В языке MQL5 предусмотрена обработка некоторых предопределенных событий. Функции для обработки этих событий должны быть определены в программе MQL5: имя функции, тип возвращаемого значения, состав параметров (если они есть) и их типы должны строго соответствовать описанию функции-обработчика события. Именно по типу возвращаемого значения и по...
应用程序是独立的，GUI是独立的。
但无论如何，对GUI中扣除的数据的处理是同步进行的。
例如，应用程序向GUI发送10000个元素，GUI按顺序处理所有这些元素。
这就是问题所在。 有必要在GUI中对传入的元素及其输出进行并行处理。基础、文本、图标。
更有甚者，每个细胞有三个循环。
这就对了。但是，在目前情况下，并行处理是不方便的。我们需要连接更多的EA或服务。它将会变成一个繁琐的、脱节的实施。
有一种基于对象图的方法。我还没有进入它，但它可以帮助我创建几个主题。这与模板有关系...
我明白了，应用程序是独立的，GUI是独立的。
但无论如何，GUI中对输出数据的处理是同步进行的。
因此，例如，应用程序向GUI发送10000个元素，GUI按顺序处理所有这些元素。
这就是问题所在。有必要在GUI中对传入的元素及其输出进行并行处理。基础、文本、图标。
越是这样，因为每一个单元有三个周期。
这不太可能奏效。即使是winda也是在单线程中处理界面。否则，窗口和控制将不会被优先考虑。只有GUI本身和各种数据的处理可以被划分为线程。事实上，即使是改变控件 中的数据也不允许从另一个线程中进行。一个对话框必须始终是连贯的，所以任何对话框的任何渲染和反应都是严格在一个线程中进行的，也就是说，一切都在同步进行。
MT中的所有操作都是严格的同步操作，除非开发者在应用程序中增加线程，否则这一点是无法真正改变的。
令人相当惊讶的是，开发人员正试图在与数据库、与Python、与Sharpe.Net合作方面扩展MT功能。但他们提出要在同一条线上进行......
这实在是太神奇了。
我同意这个惊喜。
唯一的出路是为你的应用程序看到一个带有异步功能的dll。
但这样的应用程序甚至不能放在kodobase中，因为dll是不允许的。
这不太可能奏效。即使是Windows界面也是在单线程中处理。否则，窗口和控制将不会被优先考虑。只有GUI本身和各种数据的处理可以被分割成线程。事实上，即使是改变控件中的数据也不允许从不同的线程中进行。一个对话框必须始终是连贯的，所以任何对话框的任何渲染和反应都是严格在一个线程中进行的，也就是说，一切都在同步进行。
在我看来，一切都会好起来的，只是需要提前考虑异步数据处理的优先级。
也就是说，要建立一个异步处理的方案，同步处理。
我同意，并感到惊讶。
唯一的出路是在你的应用程序中看到一个带有异步功能的dll。
但这样的应用程序甚至不能放在kodobase中，因为dll不允许。
事实上，目前还没有真正需要将GUI事件处理 并行化。如果1000个单元格的表格即使在MT4上也能运行得比较快，那么其余的事件就有足够的速度了。在我的实践中，没有减速。如果你需要超快速的动画，你可以连接OpenCL。MT5完美地拉动了常规GUI。一点问题都没有。我刚刚表明，在画布重绘方面，人们必须非常注意。
如果专家顾问本身包括繁重的计算，可以减少GUI中的数据输出频率。一个大窗口的重绘时间可能达到100毫秒，但通常要短得多。因此，只有在非常繁重的EA计算中，GUI上100ms的延迟才是明显的。
我同意，并感到惊讶。
唯一的出路是为你的应用程序编写一个带有异步函数的dll。
但这样的应用程序甚至不能放在kodobase中，因为dll是被禁止的。
很多事情都可以在DLL级别完成。
这都是MT没有设计的，可以+必须+在那里做:-)
你无法控制Dll，这就是为什么它不在市场上。顺便说一下，你可以在kodobase中找到dlls。也许他们现在出于某种原因禁止了它。
PS顺便说一下好奇的问题--DLL可以用开发者的密钥签名。在市场和kodobeise中也有可能允许这样的DLL，但它将与微软的基础设施相联系。这里有谁准备为Visual C购买这样的许可证？我同意，并感到惊讶。
唯一的出路是为你的应用程序看到一个带有异步功能的dll。
但这样的应用程序甚至不能放在kodobase中，因为dll被禁止。
是的，这就是主要的问题!同一市场禁止使用dlls，所以我们必须重新发明轮子。好吧，如果有人认为GUI是不需要的，但在任何情况下，任何复杂的长计算在一个线程中都不会工作，所有的东西都会挂起！这是不可能的。所以它必须在一个小房间里进行......这在市场上是被禁止的......。
以此类推。由于这个原因，我必须用mql方法来绘制和解决一切问题。
事实上，将GUI和逻辑分离成线程，当然已经是可能的。在这里，人们已经讨论了平行性问题，https://www.mql5.com/ru/forum/288985/page5#comment_14722396。
因此，表格本身可以留在主线程中，就像在winnda中那样，而任何额外的计算都可以移到 "后台 "执行。这就是windows、linux和android的工作方式。
你可以在DLL层面上做很多事情。
这就是MT的作用，可以+必须+做:-)
你无法控制dll，这就是为什么它没有进入市场。顺便说一下，我们在kodobase中有dlls。也许他们现在禁止了它，因为有一些大惊小怪。
PS顺便说一下好奇的问题--DLL可以用开发者的密钥签名。在市场和kodobeise中也有可能允许这样的DLLs，但它将与微软的基础设施相联系。这里有谁准备为Visual C购买这样的许可证？是的，你不能控制dll，但你可以允许同样的风库...
甚至不要走那么远：即使是作为标准库 的一部分，也有访问winAPI的函数但这有什么意义呢？毕竟，你不能把它放在市场上....。
好了，说了这么多，我们又陷入了一场洪水。
在DLL层面上，你可以做很多事情。
这就是MT的目的，可以+必须+在那里做:-)
你无法控制Dll，这就是为什么它不在市场上。顺便说一下，你可以在kodobase获得dlls。也许他们出于某种原因禁止了它。
PS顺便说一下好奇的问题--DLL可以用开发者的密钥签名。在市场和kodobeise中也有可能允许这样的DLLs，但它将与微软的基础设施相联系。这里有谁准备为Visual C购买这样的许可证？为什么你需要被束缚在微软的基础设施上？
我认为，只要是由MQ控制的，绝对可以用任何密钥来签署一个dll。
由此可见，这些密钥必须由MQ发出，并控制应用程序的哈希量。
他们为什么要把自己捆绑在微软的基础设施上？
我认为任何密钥都可以用来签署一个dll，只要它是由MQ控制的。
由此可见，这些密钥必须由MQ发出，并控制应用程序的哈希和。
但因为微软是这个蚁穴的老板 :-)
你认为为什么人们在升级和激活盗版醋的产品时，会丢失他们的登录信息？