服务台。投诉，建议。
有人说，"让我们把这个讨论带到论坛上去"。
你打算在论坛上讨论什么，是我的粗野还是内存清理的问题？
Slawa:
你被告知 "让我们把这个讨论带到论坛上"。
你打算在论坛上讨论什么，我的无礼还是内存清理问题？
所以我把讨论放在论坛上。让我们使之兼容。
关于无礼的问题。与Searcydesk交谈并不总是好事。上面的论点。
关于功能。我已经给出了证据，证明该功能没有正常工作。你给了我 "拐杖"。如果你没有拐杖就不能正常工作，请在文件中加入对这些拐杖的描述，以免将来出现问题。
我想征求一下程序员的意见。你对SeriesInfoInteger()函数的 行为满意吗？你对语言文件是否满意？
我很早以前就提出了指标中的数据问题!
https://www.mql5.com/ru/forum/42180
有人向我保证，问题已经解决了。
他们甚至在发布的摘要中写到了这一点 1200
17:终端: 修正了一个错误，尽管从MQL5程序中定期访问数据，但还是导致历史数据被卸载为未使用。
所以问题没有得到解决？
ФОРТС Прошу помощи
- www.mql5.com
Прошу откомпилировать этот код и "бросить" индикатор на символ MIX-6. - - Категория: автоматические торговые системы
Михаил:
我很早以前就提出了指标中的数据问题!
https://www.mql5.com/ru/forum/42180
有人向我保证，问题已经解决了。
他们甚至在发布的摘要中写到了这一点 1200
终端：修正了一个错误，尽管从MQL5程序中定期访问数据，但该错误导致历史数据被卸载为未使用。
所以问题并没有得到解决？
在这种情况下，我指的是MT4。但对于MT5来说，这个问题也是相关的。
Alexey Kozitsyn:
在这种情况下，我指的是MT4。但对于MT5来说，这个问题也是相关的。
我还没有更新到1200，不能检查它是否被修复。
但在MT5中存在这样一个错误
Михаил:
现在它正在加载1204。我们将拭目以待。
我还没有升级到1200，不能检查它是否已经修复。
但在MT5中存在这样一个错误
Alexey Kozitsyn:
现在它正在下载1204。让我们来看看。
在1200上检查过（bx演示），似乎已经修复了:)
现在它正在下载1204。让我们来看看。
如果不使用MT5函数SeriesInfoInteger，而使用旧的MT4函数，iBars, iTime, MarketInfo等，那么问题仍然存在？
在四，我们将修复它--过度地积极卸载未使用的图表。
下午好。今天我再次遇到这样的事实：服务台不仅不总是愿意听到问题，而且甚至不愿意听它。让我们开始吧。
几天前，我又给servicedesk写了一个请求。请求的主要内容如下（针对MT4）。
Индикатор находится на ТФ, старше М1. Пытаюсь получить данные через функцию SeriesInfoInteger() с ТФ М1. Функция возвращает нули для свойств SERIES_BARS_COUNT, SERIES_FIRSTDATE, SERIES_SERVER_FIRSTDATE после того, как на М1 образовался новый бар. До того, как образовался новый бар - данные возвращаются корректные. После - нули.
第二个问题，属于类似的类型。该指标在TF MN1上。我正试图通过函数SeriesInfoInteger()从TF M5接收数据。有一段时间，该函数返回正确的值，然后它就不再这样做了，而是开始返回零，尽管M5上没有新的酒吧被打开。
在这两种情况下，在返回到我试图获得数据的TF并切换到更高的TF后，数据有一段时间是正确的，但随后就是零了。
该指标在应用程序中。
我需要SeriesInfoInteger()函数的上述属性来检查/加载除指标以外的TF的可用历史。
没有一个程序员会喜欢以下类型的模糊性：一开始有数据，然后没有数据，无法获得数据。此外，为其编写程序的用户将不喜欢它。你可以从信息中看到，我已经提供了测试这个错误的程序。进一步甚至提供了一份日志。
数据被简单地丢弃，只能通过改变TF到数据请求的那个TF来进一步检索。
而这是我从SR得到的回应。
状态：打开关闭
你可以从信息中看到，服务台（或他们的一些员工）根本不关心用户写的错误。我被提示访问数据的频率超过了每10秒一次！？日志显示，数据被请求的频率要高得多，每一次打勾都会被请求。我相信这篇日志甚至没有人看过。但有人建议我 "更经常地 "访问它们，或从EA访问数据。天才。哦，申请立即被关闭，好像我得到了帮助。
继续前进。这是我的回答。
你确定了这个错误吗？
和服务台的回答。
打开所需的图表，那么它的数据将一直在内存中，直到你关闭它。
从Build 900开始，我们已经实现了积极的内存释放。如果有内存问题，所有能被释放的东西都会被释放。
我需要这些属性，以便选择有足够数据的适当的最小的TF。而我，则是被提出来要打开每一张图表。而且，我同时分析多少个工具并不重要，打开所有可能的图表，你就会很高兴。
关于积极的释放和记忆问题。该终端没有记忆问题。终端日志中没有错误。由此我们可以判断，我只是被告知了一种可能释放记忆的情况。但这显然不是我的情况。另一个事实是，服务台不想研究这个问题，只想把它解决掉。
下一步。
你不认为完善积极的内存释放比充实图表更好吗？那你说的是什么记忆问题呢？是的，请释放，但要让他们有可能在不拄着拐杖的情况下进一步找回!
你是否尝试过从应用程序中运行该指标？你是否明白，数据来自于别人的TF，来了，来了，然后咣当一声--就不做了！？这是正常的行为吗？
下面是文档中的一个片段。
对于专家顾问和自定义指标，最好使用基于事件的处理模式。如果onTick()或OnCalculate()事件没有得到所有必要的数据，你应该退出事件处理程序，期望在下次调用该处理程序时，数据会被获得。
我引用的指标正是使用这种模式。如果没有收到数据，预计数据将在下一个刻度上到达。但是，数据不再来了!一点也不!这是一个文件的矛盾!
在mql5中，一切工作都是应该的，为什么在mql4中不能以同样的方式组织？
而答案是。
不，它没有。
关于文件--这里有一个直接的结论：如果你经常需要一些符号周期的数据，那么要确保在OnInit中不断出现这些数据。例如，用简单的iTime(need_symbol,need_period)查询。并保持这个iTime上的每一个刻度。
你自己在给你的终端机增加记忆负担。所以要把图表上的条数减少到必要的限度。为了备份关键数据，用正确的符号-周期打开图表。
如果你对目前的状况不满意，让我们在论坛上讨论。在这里讨论它是没有用的。
MT5在使用历史数据方面有一个完全不同的模式
按顺序排列。
不，似乎不是这样的。
只是粗野的。没有解释，没有评论。
关于文档--这里的结论很直接：如果你一直需要一些符号-周期数据，那么要确保这些数据在OnInit中一直存在。例如，用简单的iTime(need_symbol,need_period)查询。并保持iTime上的每一个刻度。
第一个常识性的拐杖 。直截了当的推论！？这个结论在哪里！？你真的认为每个在mql中写作的人都为自己得出了这个结论吗！？不要为人猜测。从所写的内容中得出结论。作为比较。在mql5的文档中，在 "数据访问的组织 "一节中，有一个如何组织数据访问的例子。一切工作都很完美。这里你必须猜测，如果SeriesInfoInteger()函数返回0，你必须调用iTime()函数来获得所需的符号/周期。为什么没有写到它呢？为什么我们不能简单地改进SeriesInfoInteger()函数而不用这些拐杖呢？或者至少在文件中澄清一下？亲爱的开发者，如果你想减少问题，请在文档中详细地写一遍如何做和做什么。人们可以阅读!
你自己在给你的终端机增加记忆负担。
我想知道你想告诉我什么!终端可以消耗内存，但让终端的内存超载对我来说是件新鲜事。
所以要把图表上的条数减少到必要的限度。为了备份关键数据，用正确的符号-周期打开图表。
你认为我在应用中测试了多少个条形的指标？你似乎并不关心，因为你甚至没有问。这是个5000的数字。这是最起码的可能。并再次提出打开图表的建议。我知道了，谢谢你。将其添加到文件中（如有必要）。
而最后。
如果你对目前的状况不满意，让我们把这个讨论带到论坛上。在这里讨论它是没有用的。
MT5有一个完全不同的历史数据使用模式
是的，我对目前的状况不满意。用户在你的程序中发现了错误（我仍然认为SeriesInfoInteger()函数的行为是一个错误）。他们这样做是免费的。也不是说你不想解决这些问题，你甚至不想听他们的意见，看用户给出的数据。而且这也不是第一次了，当事实被报复性地接受，而你却不在乎错误。我希望开发商能听取意见，将来会有积极的变化。你目前的态度将使人们对你和你的产品的态度变得不受欢迎。
感谢大家的阅读。
如果有人想测试这个功能，指标就在附录中。