int CTickHistory::LastTicks(MqlTick &_ticks[])
{
if(m_lasttick<=0) return(-1); //нет загруженной историиint n=CopyTicks(m_symbol,tk,COPY_TICKS_TRADE,m_lasttick,TICKHISTORY_MAX_TICKS);
if(n>m_lastcount)
{
n=ArrayResize(_ticks,n-m_lastcount);//размер массива под новые тики
ArrayCopy(_ticks,tk,0,m_lastcount,n);//копирование только новых тиков//определим количество всех тиков, приходящихся на последний момент времени,//необходимое для отсечки загруженных тиков при следующем вызовеif(m_lasttick!=_ticks[n-1].time_msc)
{
m_lasttick=_ticks[n-1].time_msc;
m_lastcount=1;
for(int i=n-2; i>=0; i--)
{
if(_ticks[i].time_msc<m_lasttick) break;
m_lastcount++;
}
}else m_lastcount+=n;
}else n=0;//нет новых тиковreturn(n);
}
2016.08.2610:42:23.685 DealsLent (RTS-9.16,M1) Pred tiks
2016.08.2610:42:23.685 DealsLent (RTS-9.16,M1) Prev ticks, element 0 time = 2016.08.2610:42:15.5762016.08.2610:42:23.685 DealsLent (RTS-9.16,M1) Prev ticks, element 1 time = 2016.08.2610:42:15.5952016.08.2610:42:23.685 DealsLent (RTS-9.16,M1) Curr tiks
2016.08.2610:42:23.685 DealsLent (RTS-9.16,M1) Curr ticks, element 0 time = 2016.08.2610:42:15.5952016.08.2610:42:23.685 DealsLent (RTS-9.16,M1) Curr ticks, element 1 time = 2016.08.2610:42:17.2252016.08.2610:42:23.685 DealsLent (RTS-9.16,M1) Curr ticks, element 2 time = 2016.08.2610:42:17.2252016.08.2610:42:23.685 DealsLent (RTS-9.16,M1) Curr ticks, element 3 time = 2016.08.2610:42:17.2252016.08.2610:42:23.685 DealsLent (RTS-9.16,M1) Curr ticks, element 4 time = 2016.08.2610:42:17.2252016.08.2610:42:23.685 DealsLent (RTS-9.16,M1) Curr ticks, element 5 time = 2016.08.2610:42:17.235
我没有深入思考,我看到的是来自深处的 "粘附"。
为什么要思考?
运行指标,自己看看吧!
而且你甚至读过所写的东西吗?
我看过了,但现在招标已经结束了,我再检查一下(在我的脚本上)向哪个方向下载蜱虫。
你不应该在脚本 上检查,而是在RTS-9.16 chavs上运行指标,时间是-8-9pm,莫斯科时间(看看)。
而且,刻度线并不总是 深度复制,只有当新区块的第一个刻度线与前一个区块的时间相同时,才会复制。
你必须等待新的 刻度线(块),而不是复制后的事实。
如果你运行你的脚本,它将会很好,因为它将从历史记录 中复制,而不是
不是"等待"新区块。
有必要不在脚本上检查,而是在莫斯科时间晚上8-9点在RTS-9.16 chavs上运行指标。
而且,刻度线并不总是 按深度复制的,只有当一个新区块的第一个刻度线与前一个区块的时间相同时,才会复制。
你应该 期望有新的 刻度线(块),而不是复制后的事实。
我有一个指标,它输出20-30个最后的刻度。我想我可以给它加上一个检查:检查所有收到的蜱虫,看它们是否在有异常时间的历史蜱虫中。
你将无法 "栓住 "检查(这对我不起作用),因为你不知道它们是否是旧虱子。
检查的标准是什么?只有当指示器和磁带并排放置时,才能通过 "眼睛 "看到这一点。
但你将不得不等待很长时间(正如我所说的,只按一个标准深入复制)。
请记住,该缺陷只在两种条件下出现。
1.我们 "等待 "新的蜱虫(块)。
2.只有在新的区块中,第1个刻度的时间与上一个区块的前一个刻度的时间相同时,它才会在深度上被 "粘上"。
你将无法 "栓住 "检查(这对我不起作用),因为你不知道它们是否是旧虱子。
检查的标准是什么?只有当指示器和磁带并排放置时,才能通过 "眼睛 "看到这一点。
但你将不得不等待很长时间(正如我所说的,只按一个标准深入复制)。
请记住,该缺陷只在两种条件下出现。
1.我们 "等待 "新的蜱虫(块)。
2.只有在新的区块中,第1个刻度的时间与上一个区块的前一个刻度的时间相同时,它才会在深度上被 "粘上"。
砍掉不必要的东西--计算和绘制指标。只留下获取和检查刻度线阵列。为了寻找一个错误(不管是谁的),你需要尽可能地简化代码。
如果我的代码中有一个错误,它就会一直显示出来。
但现在,该指标工作正常(我用表中的数据检查了很多次)。
如果你在中等流动性的工具上运行指标,可以清楚地看到这一点。
而且几乎不可能 "在两棵松中迷失方向"(这段代码中没有任何一行可以被削减:( )。
如果我的代码中有一个错误,它就会一直显示出来。
但现在,该指标工作正常(我用表中的数据检查了很多次)。
如果你在中等流动性的工具上运行指标,可以清楚地看到这一点。
而且几乎不可能 "在两棵松中迷失方向"(这段代码中没有任何一行可以被砍掉:() )。
这里有一个例子,函数返回最后的ticks,是从我的tick历史 处理类中提取的,但我想,从代码中一切都会很清楚。
滴答请求模式--滴答的最后 "滴答"--即时间为 "0"。
一个指标(在左图)在OnCalculate()中要求CopyTicks(),第二个指标(在右图)在OnBookEvent()中要求CopyTicks()。
这里是图片。
滴答时间显示如下:索引为 "0 "的元素在图表的最底部,索引为 "0 "的元素的滴答时间是最古老的。索引为 "29 "的元素具有最年轻的滴答时间。我们在这里:我发现,至少在这个图中,有两个不一致的地方,下面是第一个例子。
这是一个例子,该函数返回最后的ticks,是从我的tick历史 处理类中拉出来的,但我想从代码中可以看出这一点。
下面是我的代码中的防止重复的方法。
将 COPY_TICKS_ALL 改为 COPY_TICKS_TRADE,似乎可以正常工作了。
但我将继续检查。:)
我不能静态地看磁带,所以我等着清场。