对MT5的祝愿 - 页 23

[Вадим]

不能在节目结束时描述这些课程，而只能在开始时描述，这不是很方便。

[Вадим]

如果能在编辑器中做一个滑块，把编辑窗口分成两个独立的窗口，就像在Word中那样，那就好了。如果能同时抄写和观看两段节目，就很方便了。

[Yuriy Zaytsev]

MetaDriver:

我希望...

唯一的例外（也不是必须的）是周末。 它们也可以被跳过，但同样可以保证在不同的乐器之间保持同步。

你知道吗？事实上，在周末的时候，外汇的工作。

只是，大多数经纪人都不工作

---

有些甚至在周末给你报价，让你在订单上工作。

这是很方便的。

他们可以在周末扩大价差，因为没有流动性。

但有一种方法可以掩盖和改变事情的真相

[Вадим]

在标准库中 添加一个函数来处理这种形式的字符串将是一个好主意。将字符串分解成由 "开始"、"结束 "限定的模块，并将其写入字符串数组。例如：int count=(string, array,"<h1>","</h1>",flag); 其中string是输入字符串，array是输出字符串阵列，"<h1>"- 字符串中模块的开头，"</h1>"。- 模块结束在字符串中。flag - 指定是否在输出数组字符串中包括或不包括模块限制器，count - 找到的模块的数量。

在这种情况下，int count=(string, array,"<h1>","</h1>",flag); - 将创建所有标题的数组，这些标题都是字符串。

[Rashid Umarov]

这也可以用现有的工具来完成，见文章《用MQL4解析HTML》。

[Вадим]

Rosh:
这可以用现有的工具来完成，请阅读文章《用MQL4工具解析HTML》。

那么，很明显，你可以用现有的工具一步一步地做。但是，有一个现成的函数，一次完成所有的事情，比两页代码要好....。

[Dmitry Voronkov]

Rinng:
好吧，这可以理解，你可以用现有的工具一步一步地做。但比起两页的代码，有一个现成的函数可以一次完成所有的事情要好....。

把它添加到一个库或mqh文件中，就没有问题了；））。

[Вадим]

在编辑器中，隐藏/打开一些程序代码块会很有用。例如 "函数"、"定义"、"类"......，或者你可以隐藏/打开子代码，例如for，if。

[x572intraday]

Rosh писал(а) # :
阅读数据访问的组织，它告诉你如何正确请求历史。

报告。并进行了分区。而我已经掌握的。如果有必要，很有可能想出办法。我还没有学会MQL，所以我对这种语言的任何问题几乎都有可能是愚蠢的。

我不明白另一个问题："参数 "图表中的最大条数 "限制了HC格式的图表、指标和mql5-程序的条数。这一限制适用于所有的时间框架数据，主要是为了节省资源。

当设置这个参数的高值时，我们应该记住，如果有足够深的低时间段的价格数据历史，存储时间序列和指标缓冲区的内存消耗可以达到数百兆字节，并达到客户终端程序的内存限制（MS Windows的32位应用程序为2GB）。

也许，我还没有真正理解这一集的内容，同时我想再次强调，我不会在这里问任何关于MQL程序的问题，但上述节省资源的动机与直接手工操作图表时终端的自动历史请求相比，看起来很奇怪。你的代码是封闭的，所以我无法判断这一切是如何进行的。我不知道每个蜡烛图是否是一个具有一大堆属性的真实对象，或者它是市场结构图像的一个简化图形画/渲染。如果我们省略下载缺失的历史的话题，而专注于我们已经拥有的历史，那么我们就会提出一个关于绘图方法的合理性的问题。即使你在设置中为图表设置了一定的、较大的最大条数，即使你把图表条数压缩成针状并使用非常高的显示器分辨率，如果条数从历史DBMS正确加载到屏幕上，我也不会相信整个画面会使用RAM。你是否使用后进先出原则？图表上的最大条数可以无限大，但屏幕后面的东西（即左右两边的）根本就不应该在内存中，当滚动时，它应该随着左边框架的卸载瞬间加载到RAM中，因为我们不是在和网络一起工作，而只是和本地可用的历史一起工作。我们可能在谈论什么可怕的2Gb限制？

...我可能非常不了解情况，所以提前原谅我这个乡巴佬。

[Renat Fatkhullin]

每个价格条由MqlRates 结构描述（没有其他特征），大小为52字节。

struct MqlRates
  {
   datetime time;         // время начала периода
   double   open;         // цена открытия
   double   high;         // наивысшая цена за период
   double   low;          // наименьшая цена за период
   double   close;        // цена закрытия
   long     tick_volume;  // тиковый объем
   int      spread;       // спред
   long     volume;       // объем
  };

为了估计工作数据库的大小，你需要在/bases/server name/symbol/ 目录下查找。例如，对于欧元兑美元，你可以看到以下内容。

在这个目录中，有交易服务器提供的原始压缩分钟容器。你可以看到，平均而言，一分钟的容器在1年内需要大约15MB。这是一种非常特殊的压缩格式，以尽量减少流量。

缓存目录包含了已经根据需要进行了压缩的工作数据库。

正如你所看到的，自1993年以来，分钟（实际上，在1999年之前，使用的是白天的时间，而不是分钟）大约是231兆字节，未经压缩，可供使用。然而，相邻的时钟只占用了4MB。

如果我们用52个字节乘以4 400 000条，得出的数值约为230MB。一个有一个工作缓冲区（双倍）的简单移动平均线指标将需要4 400 000 * 8 = 35兆字节的内存。

当交易员在终端设置中设置 "窗口中的最大条数 "时，他明确指定 "不超过指定的条数加载到内存中进行工作"。如果加载整个分钟历史记录（我们在M1图表上工作），应用一些沉重的多缓冲器指标，并使用专家顾问，内存成本可能会很高。我们不能认为 "我在一个窗口工作，看到500条，所以我可以卸下其余的"。你不能卸载它们--指标、专家顾问等在这些数据上生存和工作。

我们已经实现了一个非常有效的缓存模型，当数据和指标总是存储在一个数字中。这意味着在EURUSD:M1上打开5个窗口不需要创建5个数据缓冲区，而几个参数绝对相等的指标只有一个副本。当指标或图表长时间不使用时，它们的数据会自动释放，并在需要时重新提起。

此外，我们有一个64位版本的客户终端，它可以处理大量的历史记录，没有任何限制。一旦我们完成了64位环境下的MQL5测试，这个版本就会发布。