Tick story - page 8
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
OK, we'll cut it.
Last transaction price as reported by the exchange or trade/date gateway.
Generally, I recommend requesting the COPY_TICKS_INFO mode where the bid-ask will come in.
Yesterday I didn't pay attention, using COPY_TICKS_INFO mode will bid and ask prices come together? I.e. is this essentially the mode for forex?
Now just the behaviour is the same as in COPY_TICKS_ALL mode (i.e. can come separately bid (asc = 0), separately asc (bid = 0)) after requesting <5000 (approximately) ticks and both prices if more.
Also smaller amount of ticks is returned, than requested (COPY_TICKS_INFO mode, COPY_TICKS_ALL - as much as requested - so much is returned).
I think something is wrong...
I didn't pay attention yesterday, using COPY_TICKS_INFO mode will bid and ask prices necessarily come together? I.e. is it essentially a mode for forex?
It is possible not to cut :) and make a separate extended structure for CopyTicks.
There will definitely not be a separate structure.
So we will expand with a new field at the end.
Slice it like this, please:
We have this data.
We are still thinking hard about whether we have the right to expand the MqlTick structure. Those who operate with the size of this structure may suffer. Basically, for the sake of the future, we can make a clean cut and expand the structure.
By next Friday's release we will make a decision.
Those who have used MqlTick before, did sizeof(MqlTick) and those who haven't will find this situation a good lesson for proper programming.
In general:"cut to hell".
The information about OI, the current number of buy and sell orders, etc. is specific to the FORTS trading floor, it is not available on other floors (forex and stock exchanges). Therefore, inclusion of this information in the unified interface of MqlTick seems doubtful. And what about action and time_count fields, their existence would be useful indeed.
It makes no difference which structure will be included. We may include it into a separate structure, which probably will not happen in the next few years.
I have already started to remember the old DDE protocol - I will have to use QuickBooks to get this information from there.
Without exact time_count (up to ms), the necessity of ticks is doubtful.
It makes no difference which structure is included. It could be in a separate structure - which apparently won't happen in the next few years.
I have already started to remember the old DDE protocol - I will have to get this information from there to Quick.
Without exact time_count (up to ms), the necessity of ticks is doubtful.
Actually, this information is available in MT5 and broadcasted for a long time. It is available via SymbolInfoGet* functions. No one forbids making a request for this information at the moment of receiving a tick and combining it in its own data types.
Another issue is that centralised server storage, is always more reliable than your own. You don't have to think about storing quotes - it's all very convenient. But again, it is not critically irreplaceable.
Without accurate time_count (up to msec), the need for ticks at all is questionable.