Tick story - page 24
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Judging by the tick indicator queries, the time_msk field data is a multiple of 1000. i.e. we are not talking about milliseconds, the resolution is 1 second.
Question: what was the point in extending MqlTick structure then?
It is not so at you?
I have a Demo on Openbroker and a real account on the same place. On the real all Access server gives the same result. well on the demo the same. Looked at Si-6.16, RTS-6.16, SBRF-6.16. All changes are multiples of 1000.
Do you not so?
Right now, the SymbolInfoTick query returns zeros in the MqlTick structure instead of real milliseconds (a multiple of 1000)
Please wait for the next build.
PS on request CopyTicks milliseconds are given as is
I downloaded this indicator from this thread to test it. It gets the last 30 ticks exactly via CopyTicks. Alternatively, maybe I should try it on a different server (not openbroker).
>>"zeros are given instead of real milliseconds".
Not zeros are given, but always the same numbers with a multiple of 1000. (...2064, ...2064, ...3064, ..., ..., ..4064 )
I downloaded this indicator from this thread to test it. It gets the last 30 ticks exactly via CopyTicks. Alternatively, maybe I should try it on a different server (not openbroker).
>>"zeros are given instead of real milliseconds".
Not zeros are given, but always the same numbers with a multiple of 1000. (...2064, ...2064, ...3064, ..., ..., ..4064 )
Zeros are passed by the SymbolInfoTick function.
In CopyTicks real milliseconds are given. If these are 2064, 3064, 4064, it means that it was so. Why it was so, I don't know.
I looked through your code. What is the %-4d output specifier? time_msc is long, so just d does not work. It should be %I64d.
The zeros are given by the SymbolInfoTick function.
In CopyTicks real milliseconds are given. If it is 2064, 3064, 4064, so it was. Why it was so, I do not know.
I looked through your code. What is the %-4d output specifier? time_msc is long, so just d does not work. It should be %I64d.
Yes, sorry. The code is not mine. The author of the code really has a slip in StringFormat. I printed in each iteration of the loop through Print (tick.time_msc) . The result is all zeros at the end and we still get no milliseconds. TheCopyTicks requestpersists.
The zeros are given by the SymbolInfoTick function.
In CopyTicks real milliseconds are given. If it is 2064, 3064, 4064, so it was. Why it was so, I don't know.
Looked at your code. What is the output specifier %-4d? time_msc - it's long, that's why just d does not work. It should be %I64d.
Changed indicator from the first post - don't play with StringFormat, it should be like that now:
Yes, sorry. The code is not mine. The author really has a bug in StringFormat. Print (tick.time_msc) in each iteration of the loop. The result is all zeros at the end and we still get no milliseconds. The requestCopyTicks goes all the time.
Here is your indicator on MetaQuotes Demo data
Ask your broker about absence of milliseconds in ticks
Here is your indicator on MetaQuotes Demo data
Ask your broker about the lack of milliseconds in ticks
ps my client build 1340
juriy5555 :
Пока не знаю, что и у кому конкретно писать, я в этом несколько месяцев. Буду надеяться, что ОпенБрокер всё таки обновит сервер.
ps мой билд клиента 1340
I also have a question, though a little different plan, and I also wonder if the information transmitted from the ticks is correct.
A question about real volumes.
If you request information on ticks from the indicator, then the real volume goes there in the volume[] array. And, in theory, if you get information from ticks, then the volume accumulated per candle should match the value from the volume[] array.
Here is an example of test code:
Let's not get attached to the flags for now, and assume that each received tick changes the total volume of sVol (although, as far as I know, this is not the case).
We are waiting for the formation of a new candle and look at the entries in the journal. Broker Opening, real account, build 1340, RTS-6.16:
And so on, the real volume from the indicator will be much larger than the accumulated one. This raises a few questions for developers:
1. Should the volume obtained from the volume[] array of the OnCalculate() function be the same as the accumulated volume obtained from ticks? My opinion, of course, should, otherwise why indicate it in ticks?
2. Is it correct to use the OnCalculate() function to accumulate the volume, or is it better to get the volume through OnBookEvent()? The help says:
The Calculate event is generated only for indicators immediately after the Init event is sent and upon any change in price data. Handled by the OnCalculate function.
so, in theory, it is correct, but I would like to hear a comment on this.
3. Test results are shown WITHOUT flag analysis. If we analyze the flags, then, as far as I understand, you need to take volumes from ticks with flags 24 (simultaneous change in the last and volume):
But in this case, the accumulated volume will be even less. I would like to hear the developers' comments on how to correctly analyze ticks now (since all fields are recorded) and are the flags implemented correctly? The question about the correctness of the implementation arose because I did not notice ticks with flags:
The indicator file is also in the application.