用 MQL 编写的用户界面图库 - 页 54 1...47484950515253545556575859606162 新评论 Реter Konow 2024.07.28 09:30 #531 现在的主要挑战是让用户通过程序控制界面控件。 从技术上讲,这项任务并不困难,因为在用户程序和引擎的共生结合中,双方的算法都能在全局层面上看到图形内核。问题在于用户不知道如何使用内核。他不知道也不理解元素管理的原理。因此,有必要为用户提供熟悉的封装器--用户可以通过它访问内核并更改值的函数。 但这其中也有细微的差别。函数名称太长。毕竟,交互式元素的每个函数包装都应包括元素和窗口的名称。这对名称之间的定位非常必要。否则,用户很容易混淆,无法理解其功能包装。此外,名称可能会重合,这一点也不好。因此,您需要从两个部分生成名称:元素名称和窗口名称。这样就不会出现混淆,但包装器的名称会变得太长。尤其是在传递参数的情况下。此外,还需要为函数添加前缀,以便通过 intellisense 快速找到它们。这样可以有效过滤弹出式示例。方便。但是很长! 不仅如此。问题还在于传递的参数。要么为元素和窗口的每个预设 get/set-properties(获取/设置属性)编写包装器,要么每个包装器接受用户调用的全部参数列表。这非常不方便。最重要的是,这很难解释。 有一个办法,而且很简单。这就是:一组抽象属性。 全局变量在用户程序和引擎中同时可见。 工作原理 1.所有元素和窗口的包装器都将指向中心函数并传递其索引。它将使用这些索引来确定调用的目标元素/窗口。 2.调用后,用户将把选定的抽象属性设置为所需值 。 3.调用中心函数并传递 c.word "Set"(设置)。 4.4. 中央处理器将把抽象属性的值从全局变量设置为特定元素或窗口的目标属性。 5.5. 更新元素/窗口,并将抽象属性重置为零。 就是这样。 在我看来,这是一个简单而高效的解决方案,它将提供以下功能 a) 轻松访问任何元素和窗口的属性,无需向要求严格一致的函数传递参数。(另外,还限制了传递参数的数量。而且调用过程会变得冗长且不可读)。 c) 在 程序的任何地方设置/接收值时,可自由组合元素和窗口的一系列属性。 如果有人发现了缺点,请说出来。如果能在发布前协调好这个问题就更好了。 策略优化 - 算法交易, 交易机器人 交易者的工具箱: 拖动交易库(Drag Trade Library) DoEasy. 控件 (第 11 Реter Konow 2024.07.28 09:44 #532 Nikolai Semko CCanvas 类(如果使用)的 Update 函数中加入一个静态计数器,并打印该计数器,例如当 count%100 == 0 时。 尼古拉斯,值得考虑的是,我们谈论的是多个图形用户界面窗口。在上一个版本中有 17 个窗口,每个窗口都有数百个元素。每个元素都很复杂。它由一组部件组成。每个细节都是画布的一个部分,您需要通过它并在正确的位置填充必要的值。 如果我们以 10 个窗口的平均数量来计算(我记得帕普科夫曾订购过一个有 11 个窗口的界面),并想象每个窗口都有一组元素或一个表格,那么就会明白为什么整个界面的完整渲染要花费如此多的时间。让我提醒您,在界面中还有图标、阴影、表面渐变、各种框架....。那么绘制整个界面总共至少需要 500 毫秒。你对此无能为力。 如果减少窗口数量或简化图形,速度会更快。 关于重绘 - 我几乎没有纯粹的 ChartRedraw() 调用。到处都使用 _ChartRedraw 标志。当设置该标志时,ChartRedraw() 函数将 在 25 毫秒后的下一次计时器迭代 中调用。 也就是调用一次。这样可以避免不必要的重绘。只有在极少数情况下,我才会直接调用ChartRedraw() 函数 。 Реter Konow 2024.07.28 09:52 #533 Andrey Barinov #:每次更改时,全屏画布也会完全重绘,但所需时间不超过 50 毫秒... 最昂贵的是绘制文本。因此,为了避免每次都使用 TextOut,我将它们存储在数组中。结果快多了。 简单的算术在这里也行得通:10 - 17 个窗口的面积总和要比整个屏幕大得多。同意。再加上创建阴影、图标和框架所需的二次额外绘制....。 关于TextOut,我会检查并写出来。有趣的想法。 Реter Konow 2024.07.28 10:39 #534 进行测试: 进入演示项目 1.mqh 文件,将所有窗口设置为 OOI 标志。(初始化时打开)。 总共有 15 个不同大小和内容的窗口。2 个窗口带有滚动条和表格(因此它们的画布被部分隐藏,实际上长了 2-3 倍。全长可通过滑块与滚动条的比例来判断)。总绘图面积(最小)为2000*1000 像素。但我想应该不止这个数。总共绘制1158 个部分(打印核心后检查)。从零开始绘制所有画布的时间为 1600 至 1900 毫秒。 再次注意必须绘制的细节数量。阴影、图标、渐变、框架、文本。 绘制时间见截图: Реter Konow 2024.07.28 10:48 #535 也许有办法加快绘图速度。移除窗口平台的底部基座。这些是前侧后面的大画布,元素就在那里。如果去掉它们,速度会快 2 倍。我得考虑一下。 hini 2024.07.28 10:59 #536 能否仅在打开某些窗口时才绘制该窗口?一般很少同时打开十几个窗口。也没有必要。 Реter Konow 2024.07.28 11:04 #537 hini #: 能否只在某些窗口打开时才绘制它们?同时打开几十个窗口的情况很少见。没必要这样。 只有这种情况会发生,相信我。我说的只是同时 绘制所有界面窗口的第一张图。第一次绘制花费的时间最多。在此之后,所有图像都已保存,必要时还会从内存中调用。这不是问题。 您只想压缩第一次绘制的时间。 Реter Konow 2024.07.28 11:10 #538 Реter Konow #: 也许有办法加快绘图速度。移除窗口平台的底部基座。这些是前侧后面的大画布,元素就在那里。如果把它们去掉,速度会快 2 倍。我得考虑一下。 这就是我说的画布: 1. 元素所在的正面: 2. 窗口按钮(十字、最小化)、图标和名称文本所在的背面。然而,整个窗口都被染成了绿色,时间 也花 在了上面。但是,用户只能看到框架和窗口标题。原来,在这里的绘制是徒劳的: Реter Konow 2024.07.28 11:16 #539 我认为如果不绘制背面看不见的部分,第一次绘制窗口的速度至少可以加快三分之一。 我还不能确定,你需要检查一下 。 让它只绘制框架和帽子。跳过其他部分。无论如何都会有收获。 Реter Konow 2024.07.28 11:35 #540 Andrey Barinov #:每次更改时,全屏画布也会完全重绘,但所需时间不超过 50 毫秒... 最昂贵的是绘制文本。因此,为了避免每次都使用 TextOut,我将它们存储在数组中。结果快多了。 是的, 使用了 TextOut 。我会考虑如何处理它。 1...47484950515253545556575859606162 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
现在的主要挑战是让用户通过程序控制界面控件。
从技术上讲,这项任务并不困难,因为在用户程序和引擎的共生结合中,双方的算法都能在全局层面上看到图形内核。问题在于用户不知道如何使用内核。他不知道也不理解元素管理的原理。因此,有必要为用户提供熟悉的封装器--用户可以通过它访问内核并更改值的函数。
但这其中也有细微的差别。函数名称太长。毕竟,交互式元素的每个函数包装都应包括元素和窗口的名称。这对名称之间的定位非常必要。否则,用户很容易混淆,无法理解其功能包装。此外,名称可能会重合,这一点也不好。因此,您需要从两个部分生成名称:元素名称和窗口名称。这样就不会出现混淆,但包装器的名称会变得太长。尤其是在传递参数的情况下。此外,还需要为函数添加前缀,以便通过 intellisense 快速找到它们。这样可以有效过滤弹出式示例。方便。但是很长!
不仅如此。问题还在于传递的参数。要么为元素和窗口的每个预设 get/set-properties(获取/设置属性)编写包装器,要么每个包装器接受用户调用的全部参数列表。这非常不方便。最重要的是,这很难解释。
有一个办法,而且很简单。这就是:一组抽象属性。 全局变量在用户程序和引擎中同时可见。
工作原理
1.所有元素和窗口的包装器都将指向中心函数并传递其索引。它将使用这些索引来确定调用的目标元素/窗口。
2.调用后,用户将把选定的抽象属性设置为所需值 。
3.调用中心函数并传递 c.word "Set"(设置)。
4.4. 中央处理器将把抽象属性的值从全局变量设置为特定元素或窗口的目标属性。
5.5. 更新元素/窗口,并将抽象属性重置为零。
就是这样。
在我看来,这是一个简单而高效的解决方案,它将提供以下功能
a) 轻松访问任何元素和窗口的属性,无需向要求严格一致的函数传递参数。(另外,还限制了传递参数的数量。而且调用过程会变得冗长且不可读)。
c) 在 程序的任何地方设置/接收值时,可自由组合元素和窗口的一系列属性。
如果有人发现了缺点,请说出来。如果能在发布前协调好这个问题就更好了。
尼古拉斯,值得考虑的是,我们谈论的是多个图形用户界面窗口。在上一个版本中有 17 个窗口,每个窗口都有数百个元素。每个元素都很复杂。它由一组部件组成。每个细节都是画布的一个部分,您需要通过它并在正确的位置填充必要的值。
如果我们以 10 个窗口的平均数量来计算(我记得帕普科夫曾订购过一个有 11 个窗口的界面),并想象每个窗口都有一组元素或一个表格,那么就会明白为什么整个界面的完整渲染要花费如此多的时间。让我提醒您,在界面中还有图标、阴影、表面渐变、各种框架....。那么绘制整个界面总共至少需要 500 毫秒。你对此无能为力。
如果减少窗口数量或简化图形,速度会更快。
关于重绘 - 我几乎没有纯粹的 ChartRedraw() 调用。到处都使用 _ChartRedraw 标志。当设置该标志时,ChartRedraw() 函数将 在 25 毫秒后的下一次计时器迭代 中调用。 也就是调用一次。这样可以避免不必要的重绘。只有在极少数情况下,我才会直接调用ChartRedraw() 函数 。
每次更改时,全屏画布也会完全重绘,但所需时间不超过 50 毫秒...
最昂贵的是绘制文本。因此,为了避免每次都使用 TextOut,我将它们存储在数组中。结果快多了。
简单的算术在这里也行得通:10 - 17 个窗口的面积总和要比整个屏幕大得多。同意。再加上创建阴影、图标和框架所需的二次额外绘制....。
关于TextOut,我会检查并写出来。有趣的想法。
进行测试:
进入演示项目 1.mqh 文件,将所有窗口设置为 OOI 标志。(初始化时打开)。
总共有 15 个不同大小和内容的窗口。2 个窗口带有滚动条和表格(因此它们的画布被部分隐藏,实际上长了 2-3 倍。全长可通过滑块与滚动条的比例来判断)。总绘图面积(最小)为2000*1000 像素。但我想应该不止这个数。总共绘制1158 个部分(打印核心后检查)。从零开始绘制所有画布的时间为 1600 至 1900 毫秒。
再次注意必须绘制的细节数量。阴影、图标、渐变、框架、文本。
绘制时间见截图:
能否只在某些窗口打开时才绘制它们?同时打开几十个窗口的情况很少见。没必要这样。
只有这种情况会发生,相信我。我说的只是同时 绘制所有界面窗口的第一张图。第一次绘制花费的时间最多。在此之后,所有图像都已保存,必要时还会从内存中调用。这不是问题。 您只想压缩第一次绘制的时间。
也许有办法加快绘图速度。移除窗口平台的底部基座。这些是前侧后面的大画布,元素就在那里。如果把它们去掉,速度会快 2 倍。我得考虑一下。
这就是我说的画布:
1. 元素所在的正面:
2. 窗口按钮(十字、最小化)、图标和名称文本所在的背面。然而,整个窗口都被染成了绿色,时间 也花 在了上面。但是,用户只能看到框架和窗口标题。原来,在这里的绘制是徒劳的:
每次更改时,全屏画布也会完全重绘,但所需时间不超过 50 毫秒...
最昂贵的是绘制文本。因此,为了避免每次都使用 TextOut,我将它们存储在数组中。结果快多了。
是的, 使用了 TextOut 。我会考虑如何处理它。