Doesn't it work? It works for me, though not on all chart scales (1-5). On the 5th, it can get confused. It aligns horizontally. And you have it vertically.
I checked it on builds 1010 and 1016.
As it will, so it works. It may appear differently from build to build.
ZS: the problem seems to me to be the translation of the price of time into pixels
Then it turns out that theObjectGetValueByTime() function will return different values, and it will be impossible to find out if the trend line has been tied or broken using the language, etc. In short, analysis of trend lines cannot be implemented with an accuracy of a single point. And this is a problem!
For "floating" objects, it's better to give specific examples with screenshots, etc.
But in general, the problem of rendering accuracy rests on the discreteness of datum/price coordinate translation into XY coordinates on the chart, taking into account the scale on the chart. No one does a 1:1 plot at all
I built the line. In the line properties I ticked "ray to the left". I made sure that the anchor points of the line are located on different days. The line should not be lower than the corresponding higher TF to be good on timeframes above D1 as well.
Стандартные константы, перечисления и структуры / Константы объектов / Способы привязки объектов - справочник по языку алгоритмического/автоматического трейдинга для MetaTrader 5
joo: I built the line. In the line properties I ticked "ray to the left". I made sure that the anchor points of the line are located on different days. If we want the line to be good on time frames above D1 as well, it should not be lower than the one in the appropriate higher TF.
This is about "jumps" of lines on the same TF when the vertical scale changes.
Tapochun: Then it turns out that the ObjectGetValueByTime() function will return different values, and it will be impossible to find out if the trend line is tied or broken using the language, etc. In short, trend line analysis cannot be implemented with an accuracy of a single point. And this is a problem!
It can be done using the language. I have such an implementation (without using ObjectGetValueByTime).
DiPach: You can use the language tools. I have such an implementation (without using ObjectGetValueByTime).
OK, but the issue here is not even so much this function, but rather that the lines "jump", i.e. the price coordinates of points at a point in time change when the scale is changed.
Doesn't it work? It works for me, though not on all chart scales (1-5). On the 5th, it can get confused. It aligns horizontally. And you have it vertically.
I checked it on builds 1010 and 1016.
As it will, so it works. It may appear differently from build to build.
Then what are the questions?
well, they can't)
ZS: the problem seems to me to be the translation of the price of time into pixels
Then what questions?
well, they can't )
ZS: The problem, it seems to me, is the translation of the price of time in pixels
Actually only one.
Forum on trading, automated trading systems and trading strategies testing
bugs, errors, questions
Silent, 2014.11.24 12:12
Developers, are there any plans to ever get the graphics up to par in MT5?
...Maybe at least they will promise, but otherwise I don't even see the point of disturbing SR. If they fix one thing, something else will fall off.
upd with trendsetters is not the only remaining problem. There are a bunch of small ones with objects in general.
Checked it. No promlems detected.
For "floating" objects, it's better to give specific examples with screenshots, etc.
But in general, the problem of rendering accuracy rests on the discreteness of datum/price coordinate translation into XY coordinates on the chart, taking into account the scale on the chart. No one does a 1:1 plot at all
How did you check?
I built the line. In the line properties I ticked "ray to the left". I made sure that the anchor points of the line are located on different days. If we want the line to be good on time frames above D1 as well, it should not be lower than the one in the appropriate higher TF.
Then it turns out that the ObjectGetValueByTime() function will return different values, and it will be impossible to find out if the trend line is tied or broken using the language, etc. In short, trend line analysis cannot be implemented with an accuracy of a single point. And this is a problem!
You can use the language tools. I have such an implementation (without using ObjectGetValueByTime).