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

新评论
 
但最重要的是，我要完成引擎的开发。
 
Реter Konow #:

那么，简单的算术在这里也行得通：10 - 17 个窗口的面积总和比整个屏幕大得多。同意。再加上创建阴影、图标、框架所需的二次额外绘图....

关于TextOut，我会检查并写下来。有趣的想法。

我不明白你的简单算术:)。在我的运算中，不需要绘制用户不可见的像素，而且绘制画布的最大尺寸受限于以像素为单位的显示尺寸。

无论有多少窗口，我都是在一个位图中分层绘制的。窗口可以多达上百个。绘制简单的基元只需极少的时间。如上文所述，最长的是文本。但在第一次使用时，它们借助了 TextOut 的帮助，并已从准备好的数组中进一步绘制。

 

今后的工作计划需要得到批准。

我每周都会发布最新消息。周六或周日

1.在下一个版本中，我将发布完整版引擎。我将修复错误并加快渲染速度。

2.第二个版本将专门针对表格。我将恢复基本功能。

3.第三个版本--我将制作动态表格。 我希望能在一周内完成。我会努力的。

4.第四个版本--动态窗口。 我会尝试发布完成版本。


现阶段，生成器、引擎和标记语言 的基本版本已经完成。

我一定会开设一个用 KIB 代码编写的模板分支，在那里发布完成的窗口和元素组。为了方便那些想构建界面的人，我还会附上插图。

此外，我还将尝试撰写教程文章，以便人们能够充分使用各种可能性。


在这个主题中，我将继续尽可能地发布代码、图片和说明材料。我将忙于上述工作。

 
没有珀斯，还是太多了。在处理器较弱的情况下，您的界面加上所有文字、阴影等，最大运行时间为 50 毫秒。
查找错误。
运行剖析。看看哪些函数占用了 95% 的时间。
也许你正在使用 ChartGet 或 XY 函数（虽然你没有图表链接）。
总之，运行剖析。只需要 40 秒。
 
用 KIB 代码编写的模板分支，
不应该和构建器的代码混合在一起。应该作为一个独立的项目发布。
 
Andrey Barinov #:

我不明白您的简单算术:)。在我的计算中，不需要呈现那些用户看不到的像素，而且用于呈现的画布最大尺寸受限于以像素为单位的显示尺寸。

我是分层绘制的，不管有多少个窗口，都在一个位图中绘制。窗口可以多达上百个。绘制简单的原型只需极少的时间。如上文所述，最长的是文本。但在第一次使用时，它们借助了 TextOut 的帮助，并已从准备好的数组中进一步绘制。

使用一个大画布会有很多限制。我已经考虑过这个方案，甚至和 Nikolay 讨论过。

让我来解释一下：您这样做是因为您使用了标准的 Ccanvas 类。 在您工作的框架内有现成的解决方案。但我不使用 Ccanvas 类。所有的呈现代码都是个人开发的。这就是为什么我不坚持 "一个画布对应一切"的概念。在我看来，在图形环境中，这在技术上是一种不方便且低效的解决方案。使用一组位图对象并将现成的资源附加到这些对象上，比使用一个位图并在其上以编程方式建立图像交互要容易得多。这甚至难以想象。但这还不是最主要的。

试想一下，如果只有一个画布，要实现多窗口图形用户界面的概念要难得多。我不会接受这样的任务。

但即便如此，这也不是决定性的。拒绝所有图像使用一个画布的主要原因是：当只有一个画布时，移动界面窗口需要在 MQL 环境 中重新绘制。 相反，如果每个窗口都占用自己的位图对象，并通过 ObjectSetInteger() 函数进行移动，则移动对象的重新绘制工作将由 MQL 环境之外的标准函数 完成。因此，速度要快得多。

您只是有了一个不同的开发方向，在这个方向上，其他解决方案会更有效。


非常感谢 关于TextOut 的提示。我会调查这一点。

 
hini #:
模板分支是用 KIB 代码 编写 的，这些 代码
不应与生成器代码混合。它应作为一个单独的项目发布。

是的，为了便于调试，我会实现断开用户程序与引擎的连接，如果你是这个意思的话。可能是误解了。

 
Реter Konow #:

在一块大画布上工作有很多限制。我已经考虑过这样的方案，甚至和尼古拉讨论过。

让我来解释一下：您这样做是因为您使用了标准的 Ccanvas 类。 在您工作的框架内有现成的解决方案。但我不使用 Ccanvas 类。所有渲染代码都是由个人开发编写的。因此我并不坚持 "一个画布对应一切"的概念。在我看来，在图形环境中，这在技术上是一种既不方便又低效的解决方案。使用一组位图对象并将现成的资源附加到这些对象上，要比使用一个位图并在其上以编程方式建立图像交互更容易。这甚至难以想象。但这并不是最重要的。

试想一下，如果只有一个画布，要实现多窗口图形用户界面的概念要难得多。我不会承担这样的任务。

但即便如此，这也不是决定性的。拒绝所有图像使用一个画布的主要原因是：当只有一个画布时，移动界面窗口需要在 MQL 环境 中重新绘制。 相反，如果每个窗口占用自己的位图对象，并通过 ObjectSetInteger() 移动，则移动时的重新绘制工作将由在 MQL 环境外工作的标准函数 完成。因此，速度要快得多。

只是开发方向略有不同，其他解决方案的工作效率更高。


非常感谢 关于TextOut 的提示。我会调查这一点。

我没有 使用标准的 kanvas :).

我只是觉得在一个位图上实现多窗口界面更容易。不过各人有各人的想法！


在实践中，重绘整个画布似乎比使用 ObjectSetInteger 更快，等等....。

 
Andrey Barinov #:

我只是不 使用库存画布：）。

我只是觉得在一个位图上实现多窗口界面更容易。不过各人有各人的想法！

唉，并非在所有情况下都是如此。就我的任务而言，从技术上讲，使用一组有限的位图更容易。而且速度快 100%。快得多。

但是，对于其他开发工作，其他解决方案效果更好，所以是的--各取所需。:)

 
Nikolai Semko #:
没有珀斯，还是太多了。在处理器较弱的情况下，您的界面加上所有文字、阴影等，最大运行时间为 50 毫秒。
查找错误。
运行剖析。看看哪些功能占用了 95% 的时间。
也许你正在使用 ChartGet 或 XY 函数（尽管你没有绑定到图表）。
总之，运行剖析。这只需要 40 秒。

好的，我会再检查一遍的。但这不是重点绘图块不只是绘图。它的内部有逻辑迷宫来处理接收到的事件。需要它们来决定画什么和不画什么。选择从哪里获取图像，在哪里以及如何叠加图像。如果只是简单的绘制 100 条线的功能，那就没什么好说的了。但这是一个庞大的机制，可以确保绘制所有内容。

这一点值得考虑）。

1...484950515253545556575859606162...71
新评论