This article is the beginning of another series concerning development of graphical interfaces. Currently, there is not a single code library that would allow quick and easy creation of high quality graphical interfaces within MQL applications. By that, I mean the graphical interfaces that we are used to in familiar operating systems.
绝对是这样。我花了几个月的时间用MQL创建我自己的GUI框架，还没有计算我在过去创建类似这些库时的经验。最困难的部分不是事件，而是结构和几乎不可能调试的代码，因为所有的嵌套和递归，但也因为鼠标的状态，当调试开始时已经无效了。
顺便说一下，我在几个月前就向MQ提供了这些库的合作，不幸的是，我甚至没有得到答复。但事实是，标准控制 库只是一个很好的尝试，但与实际可能的情况相比，也是很糟糕的。人们可以做得更好。也许我应该在这里的市场上提供这个库，但我很害怕为它写整个文档的工作。
这根本就不是问题。OOP是基于大自然的原则。地球并不养活你，它只是提供资源，至于你是否需要，何时需要，在何处需要，则取决于你。
你的意思是，在创建一个框架的时候，只关心提供资源？我明白这一点，但不知为什么，我觉得很难实践，因为我的倾向性太强了。
例如，如果我创建了一个框架，现在我创建了按钮和单选按钮，这是一种按钮容器--当我创建单选按钮时，我的倾向是考虑依赖对象，在这种情况下是按钮，以及我如何与它交流。这是一个程序化编程的习惯，我想知道你是否在过去的某个时候完成了从程序化到OO的转变，你能指出我在这种情况下需要关注什么的清晰观点。因为我更倾向于关注按钮（从属对象），而不是辐射按钮。
我不确定我是否说清楚了，这只是一个关于指出在框架中创建一个关卡时需要关注的重要 事项的问题。
你能说说你的意思吗？我明白你说的大致意思，但不太清楚。
你的意思是，在创建一个框架时，只关心提供资源？我明白这一点，但不知为什么，我觉得很难实践，因为我的倾向性太强了。
例如，如果我创建了一个框架，现在我创建了按钮和单选按钮，这是一种按钮容器--当我创建单选按钮时，我的倾向是考虑依赖对象，在这种情况下是按钮，以及我如何与它交流。这是一个程序化编程的习惯，我想知道你是否在过去的某个时候完成了从程序化到OO的转变，你能指出我在这种情况下需要关注什么的清晰观点。因为我更倾向于关注按钮（从属对象），而不是辐射按钮。
我不确定我是否说清楚了，这只是一个关于指出在框架中创建关卡时需要关注的重要事项的问题。
也许我错过了重点，但我想给你我的意见。
我认为你太注重 "理论 "了，而在等待别人的光芒。没有一个完美的解决方案，有的是解决方案，你需要从你的经验和你的具体需求中找到它。
这个话题是从一个实际的案例开始的，它知道成为一个关于OOP的晦涩的讨论。有一个关于GUI的有趣的系列文章，你应该看一看，然后试着用标准库建立一个界面，并使用这些文章中的库，研究一下代码...或者不研究。
只是一个建议，因为我真的不知道如何才能更好地帮助你。
也许我错过了重点，但我想给你我的意见。
我认为你太注重 "理论 "了，而在等待别人的曙光。没有一个完美的解决方案，有的是解决方案，你需要从你的经验和你的具体需求中找到它。
这个话题是从一个实际的案例开始的，它知道成为一个关于OOP的晦涩的讨论。有一系列有趣的关于GUI的文章，你应该看一看，然后试着用标准库和这些文章中的库建立一个界面，研究一下代码...或者不研究。
只是一个建议，因为我真的不知道如何才能更好地帮助你。
Alain，我建立了一个界面，我也读了文章。
也许这不是讨论OO的地方，你可能是对的。
我开始讨论它是因为Doerk提出了这个话题作为对话题初学者的回应，并谈到了正确的OO方法。
初学者本人对Doerk的OO介绍很感兴趣，我认为在这里讨论是很自然的。
虽然你可能是对的，也许它太理论化了，但我的看法是，正确的OO不可能不涉及一些理论，最后它变得很实用。
我的困难是正确的OO思维，我只是想知道Doerk是否有机会从他的经验中了解我提出的心理困难。
有一个关于GUI的有趣的系列文章，你应该看一看，然后试着用标准库建立一个界面，并使用这些文章中的库，研究代码...或者不研究。
我刚刚下载了它，想看看它能做什么。第一印象显示，他们犯了和标准控制库一样的错误。在第一个例子中，一个单一的对话窗口就把CPU的使用率从10%（没有）提高到50-65%（加载）。这已经是最好的证明了，作者没有必要的经验来开发这样一个库，这不可能是一个正确的方法。
我不明白为什么MQ不提供一个专业的GUI框架，而要解释如何（不）做。大多数MQL程序员肯定想开发EA和指标，但不想为这些东西费心。
此外，他们的例子的面板在策略测试器中是死的，而这正是所有这种GUI的东西变得荒谬的地方。这不是对你或你所写的东西的批评，我自己知道，在这里根本没有更好的公开的东西可以用于MQL。
Alain，我建立了一个界面，我也读了文章。
也许这不是讨论OO的地方，你可能是对的。
我开始讨论它是因为Doerk提出了这个话题作为对初学者的回应，并谈到了正确的OO方法。
初学者本人对Doerk的OO介绍很感兴趣，我认为在这里讨论是很自然的。
虽然你可能是对的，也许它太理论化了，但我的看法是，正确的OO不可能不涉及一些理论，最后会变得很实用。
我的困难是正确的OO思维，我只是想知道Doerk是否有机会从他的经验中了解我提出的心理困难。
在这里讨论OOP是没有问题的。
我不同意你的 "OO不可能不涉及一些理论"，但这并不重要。
在这里讨论OOP是没有问题的。
我不同意你的 "OO不可能不涉及一些理论"，但这并不重要。
我刚刚下载了它，想看看它能做什么。第一印象显示，他们在标准控制库上犯了同样的错误。在第一个例子中，一个单一的对话窗口就把CPU的使用率从10%（没有）提高到了50-65%（加载）。这已经是最好的证明了，作者没有必要的经验来开发这样一个库，这不可能是一个正确的方法。
我不明白为什么MQ不提供一个专业的GUI框架，而要解释如何（不）做。大多数MQL程序员肯定想开发EA和指标，但不想为这些东西费心。
此外，他们的例子的面板在策略测试器中是死的，而这正是所有这种GUI的东西变得荒谬的地方。这不是对你或你所写的东西的批评，我自己知道，在这里根本没有更好的公开的东西可以用于MQL。
多尔克，你很可能是对的，但这不是我的观点。
你应该写一个具体的例子，说明为什么会发生这种CPU问题，向Anatoli（文章的作者）解释问题所在。我很抱歉地说，到现在为止，你所说的一切几乎都是无用的，即使你是100%正确。它只是太笼统和理论化了。无意冒犯。
问题是，这个问题太复杂了，无法给出确切的指示。这就是为什么我试图向那些有兴趣的人提供一些想法和可能的方法。不幸的是，我没有时间写一篇文章，也没有时间出版一个完整的文档库。对不起。