What is this for? In INFO-mode this behaviour is handy, but in ALL you wait to get the raw data and only the GUI shows it.
If the price has not changed, it is null. As it is, the flags appear to be an unnecessary entity. Instead of showing null prices, increased MqlTick-structure by this flag.
Does tkc store only (without null prices) flags, store only (without flags) prices, or is it irrational to have both flags and prices there?
And why is a flag introduced?
TICK_FLAG_VOLUME – тик изменил объем
Whether the volume has changed or not is totally irrelevant. Or am I misunderstanding something?
ZS Raw ALL data is needed especially for custom characters, as it directly relates to the issue of data exchange channel through custom characters.
Copitix in COPY_TICKS_ALL mode is amateurishly filling in zero Bid/Ask fields.
What it is done for? In the INFO-mode this behaviour is useful, but in ALL-mode we are waiting for the raw data, but they are shown only in GUI.
If the price has not changed, it is null. As it is, the flags appear to be an unnecessary entity. Instead of showing null prices, increased MqlTick-structure by this flag.
Does tkc store only (without null prices) flags, store only (without flags) prices, or is it irrational to have both flags and prices there?
And why is a flag introduced?
Whether the volume has changed or not is completely irrelevant. Or am I misunderstanding something?
SZY Raw ALL data is needed especially for custom characters, as it directly addresses the issue of data exchange channel through custom characters.
Do you write to servicedeck about the shortcomings you've identified?
It feels like everything goes to waste.
And why the flag?
TICK_FLAG_VOLUME - tick changed volume.
I think this is a very important indicator. How else can we know that the deal has been executed, and not just changed, moved bid ask?
Do you write to the service desk about any deficiencies you have identified?
The SD responds promptly to all requests. Further discussions are held there.
I think this is a very important indicator. How else would you know that the deal has been done and not only bid and ask have changed?
Only the flag is enough.
TICK_FLAG_LAST - the tick has changed the price of the last deal
By changing it to "trade passed". The fact that the last pricechanged - no one cares. There may be several deals in a row with the exact same price and volume. Therefore, there should only be one flag - the deal.
The SR responds promptly to all requests. Further discussions are held there.
All that is needed is a flag.
By changing it to "trade passed". The fact that the price has changed is of no concern to anyone. There may be several deals in a row with the exact same price and volume. Therefore, there should only be one flag - a deal.
If it is responsive that's good.
As for the flags:
I also had this thought, in Expert Advisors to analyze the situation, to combine matching trades, it's kind of enough.
This situation - exchange time, server time, and computer time do not coincide. How do I know that MarketClosed, if there is a deal even at the last price, it means that the trade is in progress.
And if you combine all deals at one level, it is not clear what time the level was traded?
P.S. Extra flags do not affect the volume of flags transmitted.
I also had this idea, in EAs for situation analysis, to combine coinciding trades, it's kind of enough.
Such a situation - exchange time, server time, computer time do not coincide. How do I know that MarketClosed, if there is a deal even at the last price, it means that the trade is in progress.
And if you combine all the deals at one level, it will not be clear for how long the level was traded?
Why combine at one level? I would not merge, and leave the ribbon as it is now - what came from the exchange.
P.S. unnecessary flags do not affect the volume of flags transmitted.
Flags are forced measure, because MQ don't return raw data. They modify them inside CopyTicks.
Do I understand correctly, that getting the ticks for September, for example, will always be faster through the CopyTicksRange, than through CopyTicks, because CopyTicks doesn't know via the input parameters, for which month should it pull data?
We need to get the history in the indicator as quickly as possible. It's possible to query via CopyTicksRange and get a bounce as -1, until everything is downloaded. And if you request by month: current month, then previous month, etc. It will not be slower, but the indicator will be ready to work with at least some history. Right?
Result
Copytix changes the raw data
Result
Why are unnecessary tics being generated?
The script outputs excessive ticks
Result on EURUSD Metaquotes-Demo
Copitix in COPY_TICKS_ALL mode is amateurishly filling in zero Bid/Ask fields.
What is this for? In INFO-mode this behaviour is handy, but in ALL you wait to get the raw data and only the GUI shows it.
If the price has not changed, it is null. As it is, the flags appear to be an unnecessary entity. Instead of showing null prices, increased MqlTick-structure by this flag.
Does tkc store only (without null prices) flags, store only (without flags) prices, or is it irrational to have both flags and prices there?
And why is a flag introduced?
Whether the volume has changed or not is totally irrelevant. Or am I misunderstanding something?
ZS Raw ALL data is needed especially for custom characters, as it directly relates to the issue of data exchange channel through custom characters.
Copitix in COPY_TICKS_ALL mode is amateurishly filling in zero Bid/Ask fields.
What it is done for? In the INFO-mode this behaviour is useful, but in ALL-mode we are waiting for the raw data, but they are shown only in GUI.
If the price has not changed, it is null. As it is, the flags appear to be an unnecessary entity. Instead of showing null prices, increased MqlTick-structure by this flag.
Does tkc store only (without null prices) flags, store only (without flags) prices, or is it irrational to have both flags and prices there?
And why is a flag introduced?
Whether the volume has changed or not is completely irrelevant. Or am I misunderstanding something?
SZY Raw ALL data is needed especially for custom characters, as it directly addresses the issue of data exchange channel through custom characters.
Do you write to servicedeck about the shortcomings you've identified?
It feels like everything goes to waste.
And why the flag?
I think this is a very important indicator. How else can we know that the deal has been executed, and not just changed, moved bid ask?
Do you write to the service desk about any deficiencies you have identified?
The SD responds promptly to all requests. Further discussions are held there.
I think this is a very important indicator. How else would you know that the deal has been done and not only bid and ask have changed?
Only the flag is enough.
TICK_FLAG_VOLUME - tick changed volume
Somehow didn't think about what's written in the help before.
The volume of what did it change?What does what is written above even mean?)
The SR responds promptly to all requests. Further discussions are held there.
All that is needed is a flag.
By changing it to "trade passed". The fact that the price has changed is of no concern to anyone. There may be several deals in a row with the exact same price and volume. Therefore, there should only be one flag - a deal.If it is responsive that's good.
As for the flags:
I also had this thought, in Expert Advisors to analyze the situation, to combine matching trades, it's kind of enough.
This situation - exchange time, server time, and computer time do not coincide. How do I know that MarketClosed, if there is a deal even at the last price, it means that the trade is in progress.
And if you combine all deals at one level, it is not clear what time the level was traded?
P.S. Extra flags do not affect the volume of flags transmitted.
If it responds, that's good.
About the flags:
I also had this idea, in EAs for situation analysis, to combine coinciding trades, it's kind of enough.
Such a situation - exchange time, server time, computer time do not coincide. How do I know that MarketClosed, if there is a deal even at the last price, it means that the trade is in progress.
And if you combine all the deals at one level, it will not be clear for how long the level was traded?
Why combine at one level? I would not merge, and leave the ribbon as it is now - what came from the exchange.
The tkc files are broken down by month. Questions because of this