Если мы успешно прошли все проверки, то сделаем последнюю попытку обойтись без обращения к торговому серверу. Сначала узнаем начальную дату, для которой доступны минутные данные в формате HCC.
Запросим это значение функцией SeriesInfoInteger() с модификатором SERIES_TERMINAL_FIRSTDATE и опять сравним со значением параметра start_date.
if(SeriesInfoInteger(symbol,PERIOD_M1,SERIES_TERMINAL_FIRSTDATE,first_date))
{
//--- there is loaded data to build timeseriesif(first_date>0)
{
//--- force timeseries build CopyTime(symbol,period,first_date+PeriodSeconds(period),1,times);
//--- check dateif(SeriesInfoInteger(symbol,period,SERIES_FIRSTDATE,first_date))
if(first_date>0 && first_date<=start_date) return(2);
}
}
对于程序（和程序员）来说，"不 "和 "不准备 "之间有什么区别？
如果数据没有准备好，就会有一个错误。
或者，也许这些信息也不是即时可用的，这就是为什么不显示的原因。
而为了避免 "进入 "服务器。
另外，你是我们的 "读者"...问题。
如果数据已经准备好了， 为什么还要建立时间序列呢(CopyTime(symbol,period,first_date+PeriodSeconds(period),1,times))?
这是正确的--它加载 并准备好了那里的东西。但是，由于指标中的任何延迟都会使挂在它上面的所有东西的聊天速度减慢--我们在指标中做到了如果在调用时系列还没有准备好--函数将返回一个错误并INITIALIZE数据的准备。一段时间后，它将不再返回一个错误。这就是你的日志中所发生的情况。
MigVRN!
Chukcha重读了帮助，不得不不同意你的观点。
"这就对了--它既能装载 又能准备好那里的东西。"
这是你的投机....
但是，帮助说函数SeriesInfoInteger的标识符Series_TERMINAL_FIRSTDATE
应该返回。
系列_终端_第一个日期
客户端中按符号排列的历史上的第一个日期，不分时期
它必须不准备任何东西!
终端历史上有数据--获取日期。
不 - 它返回 "0"。
新的一天，一圈又一圈。
准备好数据并与之合作。你可以说150次有问题，并得到150个关于如何处理的答案。 这是你的工作，所以要照顾好自己。
谢谢你，但你很清楚，所有的事情都必须得到证明。
SD认为，当数据存在时，返回0并不是他们函数的错误。
如果是这样的话，就必须写在文档中!
Mikalas:
应该，不应该--这就是我们谈论的全部。好吧，你可以自己看看它是如何工作的 :)
我唯一可以同意的是，哪些数据是一次性准备好的（任何时候都可以使用），哪些数据是终端在你访问时准备好的，这一点并不十分清楚。
我(！)明白，当访问任何时间序列数据（时间和价格，条数，ENUM_SERIES_INFO_INTEGER 枚举，或者 也许我忘了其他东西）时，数据不是 一次就能准备好 的。
为了避免这种情况，在帮助中写明了这一点。
因为mql5-程序可以通过任何符号和时间段访问数据，所以有可能所需时间段的数据尚未在终端生成，或者所需价格数据没有与交易服务器同步。 在这种情况下，数据准备的等待时间是很难预测的。
使用数据准备就绪的周期的算法并不是最好的解决方案。在这种情况下，唯一的例外是--脚本，因为它们没有其他的算法选择，由于缺乏事件处理。对于自定义指标，这样的算法以及任何其他的等待循环都是绝对不推荐的，因为它们会导致该符号的所有指标和其他价格数据处理的停止计算。
对于专家顾问和自定义指标，最好使用基于事件的 处理模式。如果OnTick()或OnCalculate()事件的处理还没有设法获得所需时间序列的所有必要数据，你应该离开事件处理程序，期望 在处理程序的下一次调用中获得这些数据。
应该，不应该--这就是我们谈论的全部。好吧，你可以自己看看它是如何工作的 :)
我唯一可以同意的是，哪些数据是一次性准备好的（任何时候都可以使用），哪些数据是终端在你访问时准备好的，这一点并不十分清楚。
我(！)明白，当访问任何时间序列数据（时间和价格，条数，ENUM_SERIES_INFO_INTEGER 枚举，或者 也许我忘了其他东西）时，数据不是 一次就能准备好 的。
为了避免这种情况，在帮助中写明了这一点。
因为mql5-程序可以通过任何符号和时间段访问数据，所以有可能所需时间段的数据尚未在终端生成，或者所需价格数据没有与交易服务器同步。 在这种情况下，数据准备的等待时间是很难预测的。
使用等待数据准备的周期的算法并不是最好的解决方案。在这种情况下，唯一的例外是--脚本，因为它们没有其他的算法选择，由于缺乏事件处理。对于自定义指标，强烈不建议使用 这样的算法，以及任何其他的等待循环，因为它们会导致该符号的所有指标和其他价格数据处理的停止计算。
对于专家顾问和自定义指标，最好使用基于事件的 处理模式。如果在事件OnTick()或OnCalculate()的处理过程中，你没有得到所需时间序列的所有必要数据，你应该退出事件处理程序，期望 在处理程序的下一次调用中获得这些数据。
安德鲁!
我不知道你怎么想的，但我已经和文件打交道很多年了。
看，从文件中可以看出，按照我（！）的理解，它是这样的。
1.让我们检查一下终端中是否有该符号的历史数据（SeriesInfoInteger，标识符Series_TERMINAL_FIRSTDATE）。
也许吧，我没有争论，它既建立了，又初始化了一些东西。
2.没有数据（返回一个空的历史开始日期）--到服务器上寻找数据。
如果有一个日期，我们使用CopyTime(symbol,period,first_date+PeriodSeconds(period),1,times) 函数构建指定的时间框架。
4.我们用给定的日期（SeriesInfoInteger(symbol,period,series_FIRSTDATE,first_date)） 检查时间序列的开始。
它是写在文档中的。
但当我(!)在终端中按符号(不是按时间系列!!!!) 要求历史数据时，这些数据恰好在那里
函数返回 "0"。
你认为这是对的吗？
但是，当我(!)在终端中按符号（而不是按时间序列!!!!） 询问历史数据时，这恰恰是有
该函数返回 "0"。
你认为这是对的吗？
数据（不准备）在磁盘上。数据（准备）可以在相邻的聊天记录上。但是，在运行间接关系的聊天室上没有准备好的数据。因此，存在着一个错误。它是正确的。但这并不方便 :)
虽然我自己不喜欢这样的问题--对你来说，从指标 中要求相邻的字符的数据是关键吗？(考虑到帮助中写到的内容和我的例子--一个指标如何减慢专家顾问和聊天的执行速度）。你可以绕过所有这些困难...
你要求的是 "FIRSDDATE"，而不是数据。日期可能在那里，但数据可能由于经济原因而丢失。如果目前没有被使用，为什么要为所有角色抽出数据。开发人员采取了理性的做法，即只有在用户访问这些数据时才抽出数据。这是正常的做法。你，与终端一起工作，应该知道这一点并采取相应的行动。
你没有把时间浪费在交易上，而是停留在初级的东西上，你在浪费你的时间。节省你的时间。:)
机器人在为我交易，我现在不在家......
我需要指标来改善我的交易 :)
安德烈！
我不知道你怎么想的，但我已经和文件打交道很多年了。
看，从文件中可以看出，按照我（！）的理解，它是这样的。
1.让我们看看终端中是否有关于该符号的历史数据（SeriesInfoInteger，标识符 为Series_TERMINAL_FIRSTDATE）。
也许吧，我没有争论，它既建立了，又初始化了一些东西。
2.没有数据（返回一个空的历史开始日期）--到服务器上寻找数据。
如果有一个日期，我们使用CopyTime(symbol,period,first_date+PeriodSeconds(period),1,times) 函数构建指定的时间框架。
4.我们用给定的日期（SeriesInfoInteger(symbol,period,series_FIRSTDATE,first_date)） 检查时间序列的开始。
它是写在文件中的。
但当我(!)在终端中按符号(不是按时间系列!!!!) 要求历史数据时，这些数据恰好在那里
函数返回 "0"。
你认为这是对的吗？
更仔细地阅读文件，而不是有选择地阅读。磁盘上有历史数据并不意味着对终端来说 "它肯定在那里"。在这种情况下（当从指标访问时），这些函数只对内存中的时间序列缓存起作用。这意味着进行同步内存访问，如果那里没有准备好的时间序列，将不返回日期SERIES_FIRSTDATE （数组中的第一个元素）。但当然，该请求启动了准备工作，将时间序列加载到内存中。
SERIES_TERMINAL_FIRSTDATE 请求与数据库初始化和与服务器同步有关，所以第一次调用无论如何不会立即工作。
原则上，使用SERIES_SERVER_FIRSTDATE 检查获得所需历史记录的能力。也就是说，你当然可以指望X次的历史请求，但如果终端通过 SERIES_SERVER_FIRSTDATE 确认历史的存在 ，那么相关的时间序列数据的可用性只是一个时间问题（m1数据库与服务器的同步和时间序列的生成）。