It is necessary to check not on script, but run indicator on RTS-9.16 chavs at - 8-9 PM, Moscow time.
And the ticks are not always copied in depth, but only if the first tick in a new block is with the time of the previous block.
You should expect new ticks (block) instead of copying post factum.
I have an indicator that outputs 20-30 last ticks. I think I can add a check to it: check all received ticks to see if they are in the history of ticks with abnormal time.
Karputov Vladimir: I have an indicator, it outputs 20-30 last ticks. I think I can add a check to it: check all received ticks to see if they are in the history of ticks with abnormal time.
You won't be able to "bolt on" the check (it didn't work for me) because you don't know if they are old ticks,
what is the criterion for checking? This can only be seen by "eye" if the indicator and the tape are placed side by side
But you will have to wait a long time (as I said, copied in depth by only one criterion)
Remember that the defect only appears under two conditions.
1. We 'wait' for new ticks (block)
2. It is "tacked on" in depth, only if in the new block the 1st tick has the time of the previous tick(s) of the previous block.
You won't be able to "bolt on" the check (it didn't work for me) because you don't know if they are old ticks,
what is the criterion for checking? This can only be seen by "eye" if the indicator and the tape are placed side by side
But you will have to wait a long time (as I said, copied in depth by only one criterion)
Remember that the defect only appears under two conditions.
1. We 'wait' for new ticks (block)
2. It is "tacked on" in depth, only if in the new block the 1st tick has the time of the previous tick(s) of the previous block.
Cut off unnecessary things - calculation and rendering of the indicator. Leave only get and check the array of ticks. To look for an error (no matter whose) you need to simplify the code as much as possible.
Karputov Vladimir: Cut off unnecessary things - the calculation and drawing of the indicator. Leave only obtaining and checking of the tick array. To look for an error (no matter whose) you need to simplify the code as much as possible.
If there was an error in my code, it would always show up.
But as it is, the indicator works correctly (I checked it many times with data from the table)
This is clearly seen, if you run the indicator on the mid-liquid instruments.
And it's almost impossible to "lose your way through two pines" (there is not a single line in this code that can be cut:( ).
If there was an error in my code, it would always show up.
But as it is, the indicator works correctly (I checked it many times with data from the table)
This is clearly seen, if you run the indicator on the mid-liquid instruments.
And it is almost impossible to "lose your way through two pines" (there is not a single line in this code that can be cut :() ).
You need to consider previously loaded ticks at start_time, otherwise the duplication of ticks happens.
Here's an example, function returns last ticks, pulled from my class of tick history processing, but I think, everything will be clear from the code.
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);
}
Tick request mode - last "ticks" of ticks - i.e. time is "0":
int copied=CopyTicks(_Symbol,tick_array,type,0,ticks);
One indicator (on the left graph) requests CopyTicks() in OnCalculate(), the second indicator (on the right graph) requests CopyTicks() in OnBookEvent().
And here's the picture:
The ticks are displayed as follows: the element with index "0" is at the very bottom of the chart and the tick time of the element with index "0" is the oldest. The element with index "29" has the youngest tick time. Here we are: I have found, at least in this figure, two inconsistencies, below is an example for the first one:
Fixed COPY_TICKS_ALL to COPY_TICKS_TRADE and it seems to be working properly,
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
I don't think in depth, I see "tacked on" from the depths.
Why think?
Run the indicator and see for yourself!
And do you even read what is written?
I've read it, but the bidding is closed now, I'll check again in which direction the ticks are downloaded (on my script).
You should not check on the script, but run the indicator on RTS-9.16 chavs at - 8-9 pm, Moscow time (to see).
And the ticks do not always copy in depth, but only if the first tick in a new block is with the time of the previous block.
You have to wait for the new ticks (block) and not copy post factum.
If you run your script, it will be fine, because it will be copying from the history and not
Not"waiting" for new blocks.
It is necessary to check not on script, but run indicator on RTS-9.16 chavs at - 8-9 PM, Moscow time.
And the ticks are not always copied in depth, but only if the first tick in a new block is with the time of the previous block.
You should expect new ticks (block) instead of copying post factum.
I have an indicator, it outputs 20-30 last ticks. I think I can add a check to it: check all received ticks to see if they are in the history of ticks with abnormal time.
You won't be able to "bolt on" the check (it didn't work for me) because you don't know if they are old ticks,
what is the criterion for checking? This can only be seen by "eye" if the indicator and the tape are placed side by side
But you will have to wait a long time (as I said, copied in depth by only one criterion)
Remember that the defect only appears under two conditions.
1. We 'wait' for new ticks (block)
2. It is "tacked on" in depth, only if in the new block the 1st tick has the time of the previous tick(s) of the previous block.
You won't be able to "bolt on" the check (it didn't work for me) because you don't know if they are old ticks,
what is the criterion for checking? This can only be seen by "eye" if the indicator and the tape are placed side by side
But you will have to wait a long time (as I said, copied in depth by only one criterion)
Remember that the defect only appears under two conditions.
1. We 'wait' for new ticks (block)
2. It is "tacked on" in depth, only if in the new block the 1st tick has the time of the previous tick(s) of the previous block.
Cut off unnecessary things - the calculation and drawing of the indicator. Leave only obtaining and checking of the tick array. To look for an error (no matter whose) you need to simplify the code as much as possible.
If there was an error in my code, it would always show up.
But as it is, the indicator works correctly (I checked it many times with data from the table)
This is clearly seen, if you run the indicator on the mid-liquid instruments.
And it's almost impossible to "lose your way through two pines" (there is not a single line in this code that can be cut:( ).
If there was an error in my code, it would always show up.
But as it is, the indicator works correctly (I checked it many times with data from the table)
This is clearly seen, if you run the indicator on the mid-liquid instruments.
And it is almost impossible to "lose your way through two pines" (there is not a single line in this code that can be cut :() ).
Here's an example, function returns last ticks, pulled from my class of tick history processing, but I think, everything will be clear from the code.
Tick request mode - last "ticks" of ticks - i.e. time is "0":
One indicator (on the left graph) requests CopyTicks() in OnCalculate(), the second indicator (on the right graph) requests CopyTicks() in OnBookEvent().
And here's the picture:
The ticks are displayed as follows: the element with index "0" is at the very bottom of the chart and the tick time of the element with index "0" is the oldest. The element with index "29" has the youngest tick time. Here we are: I have found, at least in this figure, two inconsistencies, below is an example for the first one:
Here's an example, the function returns last ticks, pulled from my tick history processing class, but I think it's clear from the code.
Here's the duplication prevention in my code:
Fixed COPY_TICKS_ALL to COPY_TICKS_TRADE and it seems to be working properly,
but I'll keep checking. :)
The tape can't be viewed statically, I'll wait for clearing