标准功能/方法的其他实现方式 - 页 13

 
Реter Konow:

这是该区块的开头部分,看起来是这样的。

据我了解,你已经创造了你自己的解释器语言。

  • 你将界面本身创建为该语言的文本文件
  • 主程序的主体加载文本文件并将其转换为可理解的 "字节码",基本上是一个数组。
  • 从这个数组中,界面被呈现出来

像这样吗?

另一个愚蠢的问题。

每个生成的具有不同元素的窗口是一种资源还是多种资源?

虽然,一个更好的比喻可能是HTML

正如我之前所说,你的孩子需要一个图形化的构造器。类似安德烈-巴里诺夫的 东西。

另外,你的视频剪辑 太长了。你需要把它们从45分钟减少到5分钟,甚至更好--3分钟。

 
A100:

你有没有试着自己去寻找问题的答案?

提示:在谷歌搜索中,输入 "DBL_MANT_DIG 53 52"。

是的,谢谢。找到了。

 
Nikolai Semko:

1.据我了解,你已经创造了你自己的解释器语言。

  • 你以这种语言创建界面本身的文本文件
  • 主程序的主体加载文本文件并将其转换为人类可读的 "字节码",本质上是一个数组。
  • 该阵列用于生成界面图像。

像这样吗?

还有一个愚蠢的问题。

每个生成的具有不同元素的窗口是一种资源还是多种资源?

虽然,也许一个更好的比喻是HTML语言。

正如我之前所说的--你的创意需要一个图形化的构造器。类似安德烈-巴里诺夫的 东西。

另外,你的视频剪辑 太长了。从45分钟开始,他们应该减少到5分钟,甚至更好,减少到3分钟。

1.是的,事实证明,"解释器 "的定义最适合我所创造的东西(尽管在创造的过程中我不知道它是什么)。

  • 是的,这是正确的。解释器被创建为一个文本文件。更确切地说,在与指标相连的文件中,对数组 "字符串SOURCE[]"进行了直接初始化。(用户写入 "KIB代码",从而初始化数组)。 此外,指标文件由用户编译,数组的内容使用EventChartCustom()传递给构造函数(专家顾问)。

  • 在构造函数中,用户的 "KIB代码 "以字符串的 "切片 "形式被采用。每个传递的字符串是128个字符的组合。这些字符串被切片并写入设计者一方的SOURCE数组的副本中。然后,执行 "内核构建模块",将 "SOURCE "数组的内容转换为 "int G_CORE[][]"数组的内容。这就是 "内核"。该块将一个内容转换为另一个内容,超过5000行的代码(由一组函数组成)。
  • .
  • 该转换是通过一个中间数组 "int TEMPLATES[]"完成的,它收集了所有元素和窗口平台的原型。根据来自 "SOURCE[]"(由用户创建)的指令,主内核被组装起来。从 "TEMPLATES "中提取元素的模板并转化为 "G_CORE"。
  • .
  • 当核心被构建后,"引擎"(构造器中负责控制GUI机械的部分)开始与构建的核心一起工作。它可以画出坎儿井,打开窗户。

2.每个形成的窗口由几个坎儿井(资源)组成。他们中的前两个是windows平台。早些时候,我使用的是一种不同的绘图方法,因此有些部分是半透明的,你可以通过它们看到图形。为了避免这种情况,我在背景中添加了另一个kanvas。然后,技术有了提高,但画布却停留在后台。它已经成长为一种技术,现在很难摆脱它了。但最终我将把它移走,窗口平台将由一个画布组成。

另外,"领域"(可切换的图像标签),是独立的画布。它们包含现成的图像,因此尽可能快地切换。如果我把所有的东西都画在一个画布上,不可避免地,图像切换会比较慢。总之,经过思考,我得出的结论是这是最好的选择。


3.视觉建构者过去是,现在也是,我的目标。我已经非常接近其实施的开始了。对其结构有一个了解。有其实施所需的所有概念。我知道怎么做。我所需要的只是时间。


我的发展的特点是自发 的。我不熟悉交互器或HTML语言,不知道它们如何工作。然而,这并不妨碍我创造和制作类似的东西。我想如果效果好,我就会继续做下去。:)

 
Реter Konow:

乍一看,你似乎对内存的使用非常浪费。不过,我可能是错的。

理想情况下,你的任务应该只有一个画布,支持价格图表的透明度。

如果编码正确的话,MQL5的性能应该足以在飞行中形成整个界面,而无需在内存中准备好块。

尽管我不排除牺牲内存资源来提高繁琐的界面性能的可能性。

到目前为止,我看到你的方法有一个很大的优势。

对你来说,创建一个成熟的图形化构造器会 更容易,因为生成标记代码比MQL代码本身更容易。


但这是一项艰巨的任务。
 
Nikolai Semko:

乍一看,你似乎对内存的使用非常浪费。不过,我可能是错的。

理想情况下,你的任务应该只有一个画布,支持价格图表的透明度。

如果编码正确的话,MQL5的性能应该足以在飞行中形成整个界面,而无需在内存中准备好块。

尽管我不排除牺牲内存资源来提高繁琐的界面性能的可能性。

到目前为止,我看到你的方法有一个很大的优势。

对你来说,创建一个成熟的图形化构造器会 更容易,因为它更容易生成标记代码,而不是MQL代码本身。


但这是一项艰巨的任务。

仍然有一个相对较小的内存超限。你是对的。像文本或图标这样的元素对象在内核中被 "不应该 "地赋予了235个属性,而它们自身的属性却少了好几倍。主元素对象,即基体,应该有所有的235个属性,但图标和文本对象的属性较少。这就造成了内存超限。

我们的想法是,如果我在主要项目对象行中再增加60个单元格,我就可以在其中放入文本和图标属性。这将使核心部分 "更宽",但三分之二的物体可以被移除。

将会有很好的内存节省和内核构建速度的提高。然而,这在技术上是难以实现的。有大量的工作要做。到目前为止,内存消耗和构建时间是相当可以接受的。但是,完美是没有极限的......


使用一块画布并不是一个好主意。为每个窗口使用一个画布,为每个字段使用一个画布,这要容易得多。通用的画布需要更频繁地重新绘制。对于每一个图像切换或每一个窗口转移。在滚动中...应该考虑到,重新绘制的速度并不总是很快。这不是在算法上,而是在图形的 "复杂度 "上。让我解释一下。

如果你画一个简单的矩形标签(比如说一个正方形),那就是在一个像素数组上循环,用正确的值(颜色)初始化右边的单元。

如果你用一个框架画一个正方形,那就是在一个像素阵列上的两个周期。

如果你画一个带有框架和图标的正方形,就是三个周期。

如果你画一个有表面渐变的框架的正方形,以及一个有阴影的图标,这就是像素阵列上的四个或更多的周期。

因此,图形越陡峭,你就越需要在循环中 "熨烫 "这个像素阵列,创造正确的图像。因此,对重绘的需求越少越好。

一个画布用于所有的图像,会使你不断地重新绘制所有的东西。因此,这不是一个好的解决方案。


这个任务当然很艰巨,但我可以做到。(虽然我会得到一些帮助))。

ZS,谢谢你的视频,很有启发性。:)

 
Реter Konow:


你是用鼠标调整窗口的大小吗?
如果是这样,是否会出现一个红方块

 
Nikolai Semko:

你用鼠标调整窗口大小吗?
如果是这样,是否会出现一个红方块

我不明白我们在谈论什么方块。

动态窗口可以用鼠标调整大小。不然怎么会这样呢?


ZS:动态窗口最初有一个全屏大小。此外,它还被 "修剪 "成所需的尺寸。换句话说,它的所有活力都在已经创建的位图的最大尺寸中实现。

 

继续讨论四舍五入的话题。
我发现,支持扩展的SSE4.1指令集的现代英特尔处理器有舍入指令ROUND{PS, PD} 。我相信AMD也有类似的东西。

https://ru.wikipedia.org/wiki/SSE4#SSE4a

http://o-ili-v.ru/wiki/SSE4

这是否意味着MQL5编译器在CPU级别不使用这个命令?由于我的英特尔Kaby Lake处理器支持这一套。

而且还有更多的内容,甚至是向量的标量乘法。

SSE4 — Википедия
  • ru.wikipedia.org
SSE4 — новый набор команд микроархитектуры Intel Core, впервые реализованный в процессорах серии Penryn (не следует путать с SSE4A от AMD)[1]. Он был анонсирован 27 сентября 2006 года, однако детальное описание стало доступно только весной 2007 года. Более подробное описание новых возможностей процессоров для программистов можно найти на сайте...