文章 "MQL 作为 MQL 程序图形界面的标记工具。 第一部分" - 页 3 123456 新评论 Реter Konow 2020.04.01 16:51 #21 Stanislav Korotky:没有 XML。关键是没有 MQL。我们的目标是为 MQL 创建一个 "原生 "的 MVP 级标记系统--没有任何装饰，但功能强大， 可扩展， 足以 满足有需要的用户的需求。 我们可以不讨论内部结构。 只是，对概念和设备进行描述通常比不描述要好。... 事实上，并没有图形库、标记语言或可视化编辑器的用户（也许有，但你看不到）。但人们渴望学习。如果文章中没有标记语言的概念，那就毫无意义。 写一个概念吧。 祝你好运。 Dmitry Fedoseev 2020.04.01 17:01 #22 Реter Konow:没有图形库、标记语言或可视化编辑器的用户（也许有，但不明显）。有的是想学习的人。如果文章没有标记语言的概念，那就毫无意义。 写一个概念吧。祝你好运 意义。文章中没有语言，甚至连概念本身都没有？ Dmitry Fedoseev 2020.04.01 17:01 #23 如果这种标记语言仅限于一个标准库，那么通过该库简化图形用户界面创建的最佳解决方案就是为该库编写一本普通的参考手册。 Реter Konow 2020.04.01 17:06 #24 Dmitry Fedoseev:什么意思？不是说文章中没有语言，甚至连概念本身都没有？ 作者没有描述标记语言是如何工作的。提出"标记语言是如何工作的？"这个问题，并在文章中找到详细的答案。没有。 Dmitry Fedoseev 2020.04.01 17:22 #25 Реter Konow:作者没有描述标记语言是如何工作的。提出"标记语言是如何工作的？"这个问题，并在文章中找到详细的答案。没有。 下一期可能会有。 Реter Konow 2020.04.01 17:24 #26 Dmitry Fedoseev:可能会在下一期发表。 我也觉得会在下一期。我们又不是傻瓜大家都明白 Dmitry Fedoseev 2020.04.01 18:44 #27 Stanislav Korotky:没有 XML。关键是没有 MQL。我们的目标是为 MQL 创建一个 "原生 "的 MVP 级标记系统--没有任何装饰，但功能强大，可扩展，足以满足有需要的用户的需求。我们可以不讨论内部结构。只是，对概念和设备进行描述通常比不描述要好。我也不太喜欢标准库，但没有太多选择，所以（目前）这是几个非常小和超级花哨的库之间的最佳折衷方案，反正我对这些库有很大疑问。建议那些以天真无邪的手工艺品自居的所谓编程和图形用户界面创作大师们在自己的主题中展示他们的帽子戏法。 你指的到底是谁？特别是因为它是复数，而我们在这里的人并不多。如果是单数，我会认为是指彼得......但它是复数。这不禁让人产生疑问 你为什么不用自己的名字？这样就不会产生不必要的问题了你就不能踢踢空气吗？ Реter Konow 2020.04.01 19:39 #28 关于文章的主题。我第五次仔细、中立、尽可能客观地重新阅读了全文。底线是 1.在文章开头，作者清晰明了地与读者讨论了程序中图形用户界面的相关问题。介绍了 MQL 可用的图形工具--MT 对象、库甚至视图编辑器。断言图形用户界面是必要的而不是不需要的。这是文章中清晰而令人愉快的部分。 2.加速开始。作者举了一个标准库 代码的例子，并当之无愧地批评了它--在构建图形用户界面时，它冗长、不方便、效率低。我们对他表示同情。 3.3. 接着，作者开始讨论其他语言的图形用户界面，他正确地指出，布局描述与程序代码的分离是明智的，是简化界面常规布局的一个独立分支。他列举了这些优点。这一次，作者使用了一般性短语，并提到了文学、.Net 平台、Android、XML....。他说，在那里和在这里一样，一切都在 "一个灯塔 "中，层次结构是可见的，而且还定义了 "单一控制器"。他没有澄清，只是继续说下去。对于未开化的人来说，清晰度结束了，一切都沉入了迷雾之中。在哪里，是什么，为什么.... 4- 作者 "飞 "了起来，与读者的对话变成了高速独白。清晰的表述顺序消失了：问题/主题/解决方案/示例/代码--一切都混杂在一起。当然，这对心灵感应者来说并不困难，但我们其他人就很难了。作者似乎是在飞快地为一种新语言想解决方案，并打算在文章结束前完成所有内容。就像"别插手，我来完成这一切！"。在疯狂的节奏中，思维碎片、代码、变量名和方法（也许有人知道......）一闪而过。跳跃的频率越来越高，我的脑袋已经无法应付在句子之间寻找联系的工作。阅读变得非常困难。 5.与读者的对话在前两章之后就消失了，进一步阅读也没有让我明白什么。尽管我已经很努力了。问题仍然是："作者到底提出了什么建议？ 我合上文章，除了有斑点的例子和前几段，什么都记不起来了。其他一切都成了一团迷雾。 希望在下一期中，作者能继续与读者对话，并将叙事结构保持到文章结束。 谢谢。 Алексей Мокрушин 2020.04.01 19:51 #29 德米特里-费多谢耶夫（Dmitry Fedoseyev），虽然令人不快，但插入的视频非常有趣。我笑了很久。当我读到您强调的内容时，我意识到这看起来非常愚蠢。更准确地说，不是改写，而是改进和补充。你在这个网站上的五年时间里，我读了你的很多文章，我不怀疑你的知识比我丰富得多，但我不同意你的观点，即在表达式写作 中不需要 OOP。因为在复杂的程序中，使用图形界面、在一个 EA 中结合多个 TS、保存统计数据等，OOP 对更好地组织程序代码有很大帮助，而设计模式（尽管我对它的研究还处于起步阶段）会使 OOP 的能力提高很多倍。当然，这并不意味着你应该把它推到一个小的 EA 中，在那里你可以使用普通的程序，而且编写速度也会快很多倍。如果大家感兴趣，我将介绍一个我应用 OOP 和一个模板的例子，以及它是如何简化我的生活的。如果不是太困难的话，德米特里，你能否举例说明你所说的"使用 OOP 创建一个类似委托的程序，同时还有函数指针"。或者您可以在哪篇文章中找到有关函数指针的信息。在此先表示感谢。 Artyom Trishkin 2020.04.01 20:00 #30 Алексей Мокрушин: 德米特里-费多谢耶夫（Dmitry Fedoseyev），虽然令人不快，但插入的视频非常有趣。我笑了很久。当我读到您强调的内容时，我意识到这看起来非常愚蠢。更准确地说，不是改写，而是改进和补充。你在这个网站上的五年时间里，我读了你的很多文章，我不怀疑你的知识比我丰富得多，但我不同意你的观点，即在表达式写作 中不需要 OOP。因为在复杂的程序中，使用图形界面、在一个 EA 中结合多个 TS、保存统计数据等，OOP 对更好地组织程序代码有很大帮助，而设计模式（尽管我对它的研究还处于起步阶段）会使 OOP 的能力提高很多倍。当然，这并不意味着你应该把它推到一个小的 EA 中，在那里你可以使用普通的程序，而且编写速度也会快很多倍。如果大家感兴趣，我将介绍一个我应用 OOP 和一个模板的例子，以及它是如何简化我的生活的。如果不是太困难的话，德米特里，你能否举例说明你所说的"在使用 OOP 创建一个类似委托的函数指针时更是如此"？或者您可以在哪篇文章中找到有关函数指针的信息。在此先表示感谢。 一切都在文档中，学习它，使用它。 123456 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
没有 XML。关键是没有 MQL。我们的目标是为 MQL 创建一个 "原生 "的 MVP 级标记系统--没有任何装饰，但功能强大， 可扩展， 足以 满足有需要的用户的需求。 我们可以不讨论内部结构。 只是，对概念和设备进行描述通常比不描述要好。
...
事实上，并没有图形库、标记语言或可视化编辑器的用户（也许有，但你看不到）。但人们渴望学习。如果文章中没有标记语言的概念，那就毫无意义。 写一个概念吧。 祝你好运。
没有图形库、标记语言或可视化编辑器的用户（也许有，但不明显）。有的是想学习的人。如果文章没有标记语言的概念，那就毫无意义。 写一个概念吧。祝你好运
意义。文章中没有语言，甚至连概念本身都没有？
什么意思？不是说文章中没有语言，甚至连概念本身都没有？
作者没有描述标记语言是如何工作的。提出"标记语言是如何工作的？"这个问题，并在文章中找到详细的答案。没有。
作者没有描述标记语言是如何工作的。提出"标记语言是如何工作的？"这个问题，并在文章中找到详细的答案。没有。
下一期可能会有。
可能会在下一期发表。
我也觉得会在下一期。我们又不是傻瓜大家都明白
没有 XML。关键是没有 MQL。我们的目标是为 MQL 创建一个 "原生 "的 MVP 级标记系统--没有任何装饰，但功能强大，可扩展，足以满足有需要的用户的需求。我们可以不讨论内部结构。只是，对概念和设备进行描述通常比不描述要好。
我也不太喜欢标准库，但没有太多选择，所以（目前）这是几个非常小和超级花哨的库之间的最佳折衷方案，反正我对这些库有很大疑问。
建议那些以天真无邪的手工艺品自居的所谓编程和图形用户界面创作大师们在自己的主题中展示他们的帽子戏法。
你指的到底是谁？特别是因为它是复数，而我们在这里的人并不多。如果是单数，我会认为是指彼得......但它是复数。这不禁让人产生疑问
你为什么不用自己的名字？这样就不会产生不必要的问题了你就不能踢踢空气吗？
关于文章的主题。我第五次仔细、中立、尽可能客观地重新阅读了全文。底线是
1.在文章开头，作者清晰明了地与读者讨论了程序中图形用户界面的相关问题。介绍了 MQL 可用的图形工具--MT 对象、库甚至视图编辑器。断言图形用户界面是必要的而不是不需要的。这是文章中清晰而令人愉快的部分。
2.加速开始。作者举了一个标准库 代码的例子，并当之无愧地批评了它--在构建图形用户界面时，它冗长、不方便、效率低。我们对他表示同情。
3.3. 接着，作者开始讨论其他语言的图形用户界面，他正确地指出，布局描述与程序代码的分离是明智的，是简化界面常规布局的一个独立分支。他列举了这些优点。这一次，作者使用了一般性短语，并提到了文学、.Net 平台、Android、XML....。他说，在那里和在这里一样，一切都在 "一个灯塔 "中，层次结构是可见的，而且还定义了 "单一控制器"。他没有澄清，只是继续说下去。对于未开化的人来说，清晰度结束了，一切都沉入了迷雾之中。在哪里，是什么，为什么....
4- 作者 "飞 "了起来，与读者的对话变成了高速独白。清晰的表述顺序消失了：问题/主题/解决方案/示例/代码--一切都混杂在一起。当然，这对心灵感应者来说并不困难，但我们其他人就很难了。作者似乎是在飞快地为一种新语言想解决方案，并打算在文章结束前完成所有内容。就像"别插手，我来完成这一切！"。在疯狂的节奏中，思维碎片、代码、变量名和方法（也许有人知道......）一闪而过。跳跃的频率越来越高，我的脑袋已经无法应付在句子之间寻找联系的工作。阅读变得非常困难。
5.与读者的对话在前两章之后就消失了，进一步阅读也没有让我明白什么。尽管我已经很努力了。问题仍然是："作者到底提出了什么建议？
我合上文章，除了有斑点的例子和前几段，什么都记不起来了。其他一切都成了一团迷雾。
希望在下一期中，作者能继续与读者对话，并将叙事结构保持到文章结束。
谢谢。
德米特里-费多谢耶夫（Dmitry Fedoseyev），虽然令人不快，但插入的视频非常有趣。我笑了很久。当我读到您强调的内容时，我意识到这看起来非常愚蠢。更准确地说，不是改写，而是改进和补充。你在这个网站上的五年时间里，我读了你的很多文章，我不怀疑你的知识比我丰富得多，但我不同意你的观点，即在表达式写作 中不需要 OOP。因为在复杂的程序中，使用图形界面、在一个 EA 中结合多个 TS、保存统计数据等，OOP 对更好地组织程序代码有很大帮助，而设计模式（尽管我对它的研究还处于起步阶段）会使 OOP 的能力提高很多倍。当然，这并不意味着你应该把它推到一个小的 EA 中，在那里你可以使用普通的程序，而且编写速度也会快很多倍。如果大家感兴趣，我将介绍一个我应用 OOP 和一个模板的例子，以及它是如何简化我的生活的。如果不是太困难的话，德米特里，你能否举例说明你所说的"在使用 OOP 创建一个类似委托的函数指针时更是如此"？或者您可以在哪篇文章中找到有关函数指针的信息。在此先表示感谢。
一切都在文档中，学习它，使用它。