用 MQL 编写的用户界面图库 - 页 71

新评论
 
Edgar Akhmadeev #:

我不仅知道需要什么，而且还做了模拟。以下是您更正后的代码和布局https://www.mql5.com/ru/forum/467909/page37#comment_53863397

我需要的正是（用您的话说）动态生成的表格。即以编程方式添加不确定数量的行（好吧，以常识为限），填充它们，方便地滚动表格本身，而不是滚动表格的框架。让标题保持原位。

这就是你们目前正在进行的工作。这就是我静静地坐着等待的原因。我自己不着急，你也不着急。我要长生不老到目前为止还行

我明白了，动态表和生成表对我和你来说都是必需的，所以它们会是。我会努力在新年前完成所有任务。
 
进行到哪个地步了？
 
hini #:
我们走了多远？
今天，动态和生成表格的概念正在形成，它们应该与科学图表协同工作。我们的任务不仅是发展技术部分（表格和图形），还要找到这些工具在分析工作中 "共生 "的方法。

下面是一个例子：

1.数据上传到文件中。特殊算法将其分配到表格、行和列中。

2.用户访问所需表格，选择一行并双击，即可使用该行或列中的数据绘制曲线或图表。

3.3. 用户选择表格中的所需单元格，并调用该单元格中与参数相关的数据构建新表格。

4.4. 用户可以从表格移动到图表，从图表移动到表格和饼图，"即时 "组装或生成新的表格和图表。通过简单的点击和在窗口中输入参数，用户可以从不同的 "角度 "查看数据，并在显示的图形中以不同的组合查看数据。

所有这些无疑都有助于提高工作效率，寻找数据中的关系和模式。

我计划通过表格、图形和图表来实施一个方便的数据动态工作系统。

最重要的是正确的概念。这需要最长的时间来形成。而技术实施则需要相对较少的时间。

另外，我正在准备第一篇关于图形用户界面生成器和标记语言的文章。

附注：在文章发布时，我将为代码库准备一个版本，以便有需要的人可以下载构造器。

总的来说，还有很多工作要做）。

 
我来告诉你们我的计划。

1.编写一本关于标记语言的教科书。

有必要收集一本关于标记语言的完整教科书，将其分为若干部分、章节和主题。


2.2. 撰写关于界面生成器和 KIB 语言的文章。

将完成的学习材料分成一系列文章，并在其中添加代码、图表、图片和 gif。

3.在发布第一篇文章之前，开设一个专门的主题，其唯一目的就是发布 KIB 代码模板。有兴趣的人可以借用现成的部分轻松创建图形用户界面。如果愿意，他们还可以添加 KIB 代码。

4.在第一篇文章发布之前，将最新版本的生成器发布到代码库中。

在该页面上发布包含图片、gif 和视频的详细说明手册。

5.5. 在文章开头给出生成器和安装说明的链接，在文章结尾留下模板分支的链接。这样，读者在阅读完文章后，就能立即尝试借用现成的窗口或元素组创建图形界面。然后，随着学习的深入，他们会不断尝试并改进自己的界面。

6.我认为，为了让读者轻松理解和快速掌握设计器的功能，有必要简化材料的呈现方式，并在文章中提供丰富的信息图片、可读性方案和注释代码。因此，我在撰写文章时会以 "越简单越好 "为座右铭，力求逻辑简洁、含义清晰。

7.在代码库中发布构造函数之前，我需要做一些前期工作：

a) 将目录名称翻译成英文。

b) 完全删除编译构造函数时出现的所有警告（非 KIB 代码）。

c) 修正之前在控件工作中发现的一些错误。

d) 添加一个 "存根"，用于调试连接到引擎的用户代码。

根据设想，调试时只需注释一行即可关闭引擎，只有 "UIDATA.mqh "服务文件中的图形核心和封装函数将保持连接。构造函数的所有其他常规函数将被设置为 "空函数"，在一个特殊文件中充当 "停止符"。用户将在调试前取消注释该文件的行。

这是一个概念，但我还没有在实践中验证过。


8.第一篇文章对我来说是最难的，因为它要求我简要介绍整个构造函数和标记语言，让读者对它们的目的、功能和设备有一个完整的概念。此外，我还将列出未来文章的内容，并为未来教材的发行添加一个清晰的计划。

在我看来，文章就是课程，因此，材料的呈现方式应具有教学性。

附注：最初，我决定以阿纳托利-科扎尔斯基（Anatoly Kozharsky）的著名图形界面文章--《简易快速图书馆》为例。对我来说，这是揭示这一主题的最完整的成果。同时，我也要感谢其他有才华的作者，他们在阿纳托利的文章前后为创建用户界面库做出了有价值的尝试。我要特别提到德米特里-费多谢耶夫（Dmitry Fedoseev）和阿尔特姆-特里什金（Artem Trishkin）。

因此，在接受了阿纳托利的文章作为质量标准和专业性指标之后，我 "试着 "将他们的格式与我自己的材料进行比较，并被迫认识到其中的不兼容性。方法和实现方式的差异太大了。因此，我必须找到并打磨自己的风格，同时不忘达到前辈们设定的高标准。
 

在 MT5 上使用可视化图形用户界面编辑器的过程。

4 年前：

(点击图片）。


附：下面的帖子概述了演示的背景。

 
时光荏苒，可视化编辑器的想法一直在我脑海中挥之不去。它不愿离我而去。每当我在闲暇时思考这个问题时，我都会问自己："有什么问题吗？- 我已经创建了它，只是没有打开而已"。

随着思考时间的延长，我又得出了同样的结论：可视化编辑器的基本功能在我的实现中已经存在，缺少的只是复杂的工具。不过，复杂的东西可以通过标记语言来创建，这在实践中要比可视化模式更快、更方便。

例如，表格和树状列表--手动编写它们既费时又费力，但用 kib 代码编写它们却又快又简单......尤其是使用模板时。尤其是使用模板时。既然只需复制粘贴就能创建表格和列表，为什么还要为它们发明繁琐的可视化编辑工具呢？很明显，这样做毫无意义。那么问题出在哪里呢？

其实很简单。我们的任务是将标记语言的工作与可视化编辑器的现有功能结合起来。无论是前者还是后者，都不需要添加任何新内容，只需要将它们结合起来，使其相辅相成即可。

在认真思考了这个问题之后，我得出了一个结论：即使现在有机会完全转向可视化图形用户界面构建，我也会拒绝。因为我不想失去在标记语言环境中使用 kib 代码模板和简单复制粘贴元素或属性的机会。这个优势太宝贵了。也许，不仅对我，对所有未来的用户都是如此，他们可以共享自己的开发成果，或简单地复制他们以前开发成果的一部分。这是不可或缺的。

也就是说，为了可视化编辑器而放弃标记语言是绝对不可能的。我以前不明白....

因此，现在的问题是要开发一种语言与可视化编辑器功能和谐结合的系统。实际上，从技术上讲，这很容易做到。(1）首先，可视化编辑器的所有必要功能在几年前就已经编写完成并经过了测试；（2）其次，最近几个月，标记语言的关键机制已经得到了很好的强化，并进行了重大升级，增加了软件界面管理功能。换句话说，一切都为整合和合并做好了准备，现在的任务只是在建模和构建图形界面的过程中，思考这两种功能的无冲突交互概念。

从概念上讲，标记语言和可视化编辑器确实存在冲突。

有几个原因使这项任务变得困难：

回想一下，图形用户界面的 元素和窗口都是用代码编写的，但也可以在可视化编辑器中创建，如上图所示。

1）在第一种情况和第二种情况下，构造函数的功能都是构建图形核心，尽管方式不同，但由于可视化编辑器的功能弱于语言的功能，因此创建的元素不接受用户通过编辑器进行的全套设置。可以通过编写编辑器来补充设置，但这样一来，标记语言就变得没有必要了，这是很糟糕的，因为不可能依赖代码模板。我们不能放弃标记语言。

2) 在可视化模式下创建新元素和窗口时，标记语言无法 "看到 "它们。也就是说，在图形用户界面的可视化构建过程中，标记语言不会被更新。没有任何东西被 "添加 "到原始的 kib 代码中。这一事实再次导致了可视化编辑器和标记语言在概念上的分离。这是一个冲突。

那么，在这种情况下该怎么做？怎样才能使两种强大的图形用户界面构建工具实现共生？

我将尝试了解解决方案：

要点：限制可视化编辑器在界面建模中的作用，保持语言功能不变。实际上，这意味着

1.拒绝在可视化模式下创建新元素和窗口，因为添加这些元素和窗口时，标记代码不会更新。

2.在 kib 代码中用户默认值和自定义值的基础上，通过可视化编辑器的设置窗口为用户图形用户界面的元素和窗口编辑位置和设置属性。在这种情况下，编辑器会写入并保存一个包含覆盖值的特殊文件，然后将其加载到内核中并分配给元素。事实上，这意味着在编辑器中 "处理 "了一种新的元素模板。它们不会与 kib 代码模板冲突，只会覆盖其中设置的属性值。

在我看来，这是编辑器和标记语言之间的有效共生。

附注：具有讽刺意味的是，从技术上讲，在几天内实现编辑器和语言功能的融合是可能的，也是相当现实的，但要考虑它们在用户工作 .... 中的整合和互动的所有细节，则需要更多的时间。这需要更多的时间。:)

附注：但主要结论是，它们可以而且应该相互配合，相辅相成。
 
你要做的事情需要很长时间，而你的源代码几乎没人能参与开发，你只能靠自己。
 
hini #:
你要做的事情需要很长时间，而你的源代码几乎没有人能够贡献，你只能靠自己。
我坚决不同意第一种说法。可视化编辑器的概念不仅在 4 年前就已经提出，而且在技术上已经充分实现，用户可以通过基本控件轻松组装出一个简单的设置窗口。例如，在设计器中，有带有尺寸和网格的信息标记，有用于设置属性的面板，有用于保存项目和打印 API 文件的功能，还有带有框架、图像和字体的辅助窗口。一切都和标记语言一样。

不过，要完善可视化编辑器，文件导航器是必不可少的。好消息是，文件导航器已经存在了--我之前在分支页面上展示过--尽管还需要调整，但基本功能是可行的。

除了文件导航器，我们还需要开发类似 kib 代码的模板概念。起初我认为这是不可能的，但事实证明解决方案非常简单：如果有了文件导航器，可视化编辑器就能将构建的界面保存为模板，而不是项目。毕竟，这在本质上是一回事。此外，不仅是整个项目，该项目中的单独窗口也会被保存为模板。这样做很容易，因为只保存了已构建核心的一部分，它可以加载到另一个项目中，用户可以提取（通过复制如上图所示）必要的元素，然后从他的项目中删除这个模板。我有删除窗口和元素的功能。就是这样。

根据上述 gif 中按钮的示例，只需复制单元格即可创建表格。同理。树形列表更复杂....但这并不是最主要的。

只要有足够的热情，一个月或一个半月就能完成所有工作。但现在我正忙着为文章准备素材，所以这项工作被推迟了。

至于说其他程序员无法开发项目.....是的，他们不能直接开发项目。但他们可以提供解决方案，分享他们的经验和意见，提供使用颜色和渐变的功能。我对这种互动与合作持开放态度。
 
Реter Konow #:

...

不过，要完善可视化编辑器，文件导航器是绝对必要的。它将提供选择文件夹以加载或保存项目的功能。好消息是，文件导航器已经存在了--我之前在分支页面上已经展示过--尽管还需要调整，但基本功能是可行的。
...


这里是文件导航器的工作原理（左图）。您只需将其集成到编辑器中即可。

 

本视频展示了在 MT5 可视化编辑器中创建设置窗口的过程。您可以通过它大致判断编辑器的完成程度。


1...646566676869707172737475767778...82
新评论