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

新评论
 
Vitaliy Kostrubko #:

...如何在图形用户界面的按钮上制作类似的 2-3 行标题--> 不使用 kanvas，或使用 kanvas

Will.
 
经过深思熟虑，我们做出了一项战略决策，即全力恢复可视化编辑器的功能。据粗略估计，在未来 3 周内，可视化编辑器的功能将基本完成，并可实际应用。下一步只能是开发和改进。

我将进一步解释做出这一决定的原因。
 
Vitaliy Kostrubko #:

...说到内容（关于 "未来的想法"）.....：

我目前正在 "尝试 "直接从终端对象设计一个面板：按钮和文本标签、

遇到了这种情况


-->为了 "我自己"--避免按钮的混淆--我决定在按钮的 "细节 "上签名。
因此，有必要不在按钮上题字（因为题字将出现在按钮高度的中间），而是以 "叠加 "文字的形式出现 在按钮上（！）。 这就是题字变成两行的原因：

因此，我们才会说出这种情况--以防将来您 "发明 "了一种方法--如何在GUI 中的 按钮上制作这种 2-3 行的标题-->不使用或使用 kanvas--。

对吗？:-)

不使用 GUI 编辑器 :-)

或者像这样...

或这样

:-)

只是为了记录，我有 10 分钟的空闲时间...

 
为什么没有必要进一步发展标记语言的方向？

1.入门门槛高。

用户需要了解标记语言的规则，才能构建复杂的面板。但他们只有在学习了我需要在未来 6-7 个月内编写的 ~20 个教程之后才能了解这些规则。

2.如果不了解语言规则，就不可能完全使用图形用户界面模板。

从教程中获取知识，并将这些材料印成文章。文章的发表间隔为每月一到两篇。要完成一门完整的学习课程，至少需要发表 7-10 篇文章，按此速度计算，整个过程需要 ~ 半年时间。

根据上述论点得出的结论是，只有在文章出版后再出版模板才有意义。如果用户缺乏语言实践知识，就无法根据自己的需要修改 kib 代码模板，这将大大降低模板的实用性。因此，用户会向我寻求解释和帮助。我可以帮助一两个人，但如果有更多人，我们就会走入死胡同。




现在，我们来看看为什么开发一个可视化编辑器是非常有意义的。

1.用户进入门槛低。

可视化编辑器的优势在于直观。通过探索其图形界面，可以轻松识别其功能和限制。添加工具提示有助于理解复杂性。

2.开始使用可视化编辑器所需的培训材料较少。

整个课程只需 3-5 篇文章即可完成。但即使没有这些文章，用户也能很快学会如何创建简单和复杂的面板。

3.编辑器尽可能简化和加快图形用户界面的创建。

使用标记语言和可视化编辑器的工作量差别很大。这一因素最终使天平倾向于可视化编辑器。所需的工作量较少，这对用户创建图形用户界面交易应用程序的兴趣产生了有利影响。

4.可视化编辑器的概念基础是经过深思熟虑的，其技术基础在 4 年前就已编写完成并经过测试。我们可以说，客观地说，编辑器正处于首次发布的门槛上。
 
Maxim Kuznetsov #:

对吗？:-)

这是在没有图形用户界面编辑器的情况下：-)

或者是这样。

或者这样

:-)

我只是说说，我有 10 分钟的空闲时间...

当然，也会有人想使用第三方程序来构建图形用户界面并通过 DLL 进行连接，这没有问题。

这是每个人的选择。
 
Реter Konow #:
...
4.vis.editor 的概念基础是经过深思熟虑的，而技术基础则是四年前编写和测试的。我们可以说，该编辑器即将发布。
这一点值得详细说明。

可视化编辑器（VE）需要实现最基本的功能。让我们来大致了解一下。

可视化编辑器的功能基础：

1. 编辑和可编辑元素的交互。

2.2. 将图形核心分为工作人员区和用户区。编辑和可编辑元素应分别位于内核的不同部分，前者位于员工区，后者位于用户区。

3.创建和删除元素和窗口的功能应在内核的用户部分运行，并由标准部分的元素调用。

4.4. 在图形用户界面编辑后保存内核自定义部分的功能。

5.从文件中加载已保存的内核部分（项目），以便重新设计和完善项目。


这是能正常工作的编辑器最起码的要求。


已实现的功能

1.编辑器与可编辑元素的交互。

编辑器有两个特定属性：Target_object（目标对象）和 Target_property（目标属性）。当用户点击一个可编辑元素时，该元素会进入一个特殊的焦点。此时，编辑器元素会根据 Target_property 属性将可编辑元素的属性值纳入自己的参数，并通过另一个特殊属性 Output_property 输出。也就是说，如果 Target_property 是元素的颜色，那么 Output_property 既可以是显示可编辑元素颜色名称的文本，也可以是编辑器元素的基本颜色，并随之改变。

这些元素的相互连接有许多变体，但技术实现并不困难，而且非常简单。

2- 构造函数现在有了自己的内部 API 文件，这样就可以使用封装函数和传入的图形用户界面事件，轻松使用自己的自定义窗口功能。

3. 此外，构造函数可以通过两种方式加载--直接从内核加载，绕过 kib 代码解释过程；或通过 kib 代码解释进行标准加载。因此，在图表上加载构造函数的时间从 ~1.5 秒降至 ~16 - 32 毫秒。此外，由于从内核文件加载，我们还设法消除了与 kib 代码相关的警告。但与前景相比，这也许只是微不足道。从现成内核加载的主要优势在于可以从其他文件中 "顶替 "现成内核部分，这些文件可以是用户工作所需的窗口模板或元素组。这是一步之遥。

4.构造器的文件夹和文件已完全翻译成英文。架构发生了巨大变化。

我的主要目标是创建最小功能的编辑器，让您可以绕过标记语言，由内而外地创建编辑器。

 
早些时候，我宣布了下次发布的截止日期--11 月 28 日。由于要调整可视化编辑器的方向，我不得不将发布更新的时间推迟到 12 月 10 日。除此之外，之前批准的计划保持不变。编辑器将上传到 kodobase，模板分支将开放，第一篇文章也将撰写完成。

最后两点需要说明

1）用户界面窗口模板分支将按计划打开，但不是图形用户界面图片与 kib 代码片段，而是图形用户界面图片与包含技术信息和在编辑器中重现模板所需的内核片段的 UIDATA 文件一起发布。

2) 发布后，我希望写一篇关于编辑器的文章。在这篇文章中，我将介绍入门所需的必要信息。将来，当编辑器的话题讨论完毕后，如果有兴趣和需求，我可以发布关于图形界面 交易应用程序的文章。

因此，计划几乎没有任何变化。只有日期和主题。

附注：我认为我的决定是正确的。

我的主要目标是点燃需求，让编辑器成为受欢迎的工具。这一点对于标记语言来说要难得多。我已经有机会在这个主题的页面上看到了这一点。重复这种方式--发布代码、图片和教程--但要付出更大的努力，并期待结果会有所不同，人们会争相学习这门语言.....。不，没意义。

我希望编辑器会更有用。我们拭目以待。:)

 
Реter Konow 图形界面 交易应用程序的文章。

因此，计划几乎没有任何变化。只有日期和主题。

附注：我认为我的决定是正确的。

我的主要目标是点燃需求，让编辑器成为受欢迎的工具。这一点对于标记语言来说要难得多。我已经有机会在这个主题的页面上看到了这一点。重复这种方式--发布代码、图片和教程--但要付出更大的努力，并期待结果会有所不同，人们会争相学习这门语言.....。不，没意义。

我希望编辑器会更有用。我们拭目以待。）

我认为编辑器对更多人来说是更好的选择。大多数人都不是技术人员，他们希望用一种简单的方法来产生结果。

我认为编辑器是个好主意，如果你能成功，那将会非常棒。你甚至可以把它作为一个库在市场上出售。既然你投入了这么多时间和精力，免费提供这样一个东西似乎是犯罪。

我完全支持您做编辑器的决定
 
Levi Dane Benjamin #:
...

我认为，对于更广泛的受众来说，编辑器是更好的选择。大多数人都不是技术人员，他们希望用简单的方法获得结果。

我认为编辑器是个好主意，如果你能实现它，那将会非常棒。你甚至可以把它作为一个库在市场上出售。这样的东西应该免费提供，这似乎是一种犯罪，毕竟你为它投入了那么多时间和精力。

我完全支持你制作编辑器的决定
感谢您的宝贵支持！了解其他人的意见对我来说很重要，这样我就不会迷失在自己的结论中，.....做出正确的选择。

你知道，我为自己做了一个决定，不把可视化编辑器当成什么了不起的东西。我注意到，在我的潜意识里，编辑器是不那么容易实现的。所以我试着把它看成是一种工作程序。这样我就更容易创作了。这只是心理游戏。:)

关于免费发布，这是一个经过深思熟虑的决定。现在别无他法。我不会将编辑器本身货币化，这是肯定的。但也许将来，如果有需求，我会推出一些付费功能。我们拭目以待。:)
 
虚拟环境开发过程不会停滞不前。

1.完成设计器和引擎的大规模重组。建立新的文件夹和文件组织结构。

2.对编辑器的功能进行了全面考虑。编写准备工作正在进行中。

3.考虑并编写编辑器中项目 的实施。

4.我应该指出的是，编辑器对我来说绝对清晰易懂。以至于我发现了与 Kostruktor 的直接相似之处，并意识到在很久很久以前，我就已经从一条短路变成了一条长路，因为我可以立即绕过标记语言编写一个可视化编辑器。从技术上讲，我面前就有这样一种可能性，只是我没有发现而已。我不明白，也没有意识到。但这很简单。比用标记语言构建一个构造函数简单多了。简单多了但是就是这样
1...67686970717273747576777879808182
新评论