Errors, bugs, questions - page 1931
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
It's always better in the morning... :)
In the helpdesk
MT4:
For objects with fixed size: OBJ_BUTTON, OBJ_RECTANGLE_LABEL and OBJ_EDIT properties OBJPROP_XDISTANCE and OBJPROP_YDISTANCE set position of the upper left object point relative to the chart corner (OBJPROP_CORNER), from which X and Y coordinates in pixels will be counted.
MT5:
For objects with fixed size: OBJ_BUTTON, OBJ_RECTANGLE_LABEL, OBJ_EDIT and OBJ_CHART, properties OBJPROP_XDISTANCE and OBJPROP_YDISTANCE set the position of the upper left point of the object relative to the chart corner (OBJPROP_CORNER), from which X and Y coordinates in pixels will be measured.
The matter is that the old version of MT4 using ObjectSet allows placing objects relative to their edges (corners) - for objects in the left part the calculation of pixels is performed from the first symbol, for objects in the right part - from the last symbol, while the new version always performs the calculation from the first symbol, which makes positioning of labels with text difficult, because you don't always know how many text symbols will be. I ask the developers to add a choice of text alignment method!
If anyone knows how to get left and right alignment in MT5, please share the corresponding function!
And don't get angry, but read the help carefully:
For OBJ_LABEL, OBJ_BITMAP_LABEL and OBJ_RECTANGLE_LABEL objects you can set the chart angle, relative to which the object anchor point is positioned. This angle is set via the object property OBJPROP_CORNER, which can have one of the four values of the ENUM_BASE_CORNER enumeration:
Identifier
Description
CORNER_LEFT_UPPER
Coordinates of the anchor point relative to the upper left corner of the chart
CORNER_LEFT_LOWER
Anchor point coordinates are given relative to the lower left corner of the chart
CORNER_RIGHT_LOWER
Anchor point coordinates are set relative to the lower right corner of the chart
CORNER_RIGHT_UPPER
The coordinates of the anchor point are set relative to the upper right corner of the chart
The position of the object's anchor point is specified by the OBJPROP_ANCHOR property and can be one of 9 values of the ENUM_ANCHOR_POINT enumeration:
Identifier
Description
ANCHOR_LEFT_UPPER
Anchor point in the upper left corner
ANCHOR_LEFT
Anchor point to the left in the centre
ANCHOR_LEFT_LOWER
Anchor point at the lower left corner
ANCHOR_LOWER
Anchor point below centre
ANCHOR_RIGHT_LOWER
Anchor point at the lower right corner
ANCHOR_RIGHT
Anchor point to the right in the centre
ANCHOR_RIGHT_UPPER
Anchor point at the upper right corner
ANCHOR_UPPER
Anchor point at the upper centre
ANCHOR_CENTER
Anchor point exactly in the centre of the object
Shall I move up the list item you're trying to label with the number 4, which isn't there? It becomes zero - and everything is in place.
Of course I've moved everything - maybe I'm stupid...
And don't get angry, read the help carefully:
For OBJ_LABEL, OBJ_BITMAP_LABEL and OBJ_RECTANGLE_LABEL objects you can set the chart angle, relative to which the object anchor point is positioned. This angle is set via the object property OBJPROP_CORNER, which can have one of the four values of ENUM_BASE_CORNER enumeration:
Identifier
Description
CORNER_LEFT_UPPER
Coordinates of the anchor point relative to the upper left corner of the chart
CORNER_LEFT_LOWER
Anchor point coordinates are given relative to the lower left corner of the chart
CORNER_RIGHT_LOWER
Anchor point coordinates are set relative to the lower right corner of the chart
CORNER_RIGHT_UPPER
The coordinates of the anchor point are set relative to the upper right corner of the chart
The position of the object's anchor point is specified by the OBJPROP_ANCHOR property and can be one of 9 values of the ENUM_ANCHOR_POINT enumeration:
Identifier
Description
ANCHOR_LEFT_UPPER
Anchor point in the upper left corner
ANCHOR_LEFT
Anchor point to the left in the centre
ANCHOR_LEFT_LOWER
Anchor point at the lower left corner
ANCHOR_LOWER
Anchor point below centre
ANCHOR_RIGHT_LOWER
Anchor point at the lower right corner
ANCHOR_RIGHT
Anchor point to the right in the centre
ANCHOR_RIGHT_UPPER
Anchor point at the upper right corner
ANCHOR_UPPER
Anchor point at the upper centre
ANCHOR_CENTER
Anchor point directly in the centre of the object
Thank you, I will try to think of something tomorrow...
It's always better in the morning... :)
Forum on trading, automated trading systems and trading strategy testing
Bugs, bugs, questions
fxsaber, 2017.07.18 09:51
Almost a childish question: why is it like that?For some reason I was sure that DoubleToString was meaningless after normalisation. But no, as the script shows. Why is this the case?
It seems that the double -> string conversion doesn't work correctly.
This example is rather complicated to understand, so I gave you another one.
Here's what I mean.
Строковая в double переводится без проблем. Обратно - получаем другой результат.
I.e. took the string "8.905", converted it to double and immediately to string, getting 8.90499999999999999. But the first line of OnStart shows that (double) "8.905" == 8.905. That is, 8.905 should be printed.
Of course, the obvious zero-end situation shouldn't work:
Having investigated the issue a bit, I've come to the following situation
Please explain why conversion double -> string is still considered correct. The last example is so completely blowing my mind.
Please explain why the double -> string conversion is still considered to be correct. The last example is so completely mind blowing.
Comment on the last example
Real numbers can be considered identical if they underwent the same conversions. Even seemingly identical conversions - num*0.5 and num/2.0 lead to different results. The same can be said about mirror operations. num*=num2, num/=num2. The resulting num will not equal the original num. Welcome to the world of real numbers.
During the normalization process, 3 operations were performed in this sample with a real number - num*=1000, num+=0.5, num/=1000.
You can check the steps in the debugger
SD says it is correct in this case.
Why is it confusing?
The vast majority of decimal real numbers are not representable as a binary fraction without a remainder. Put a double storage format on top of that and you get such ugly stuff.
Actually, the decimal type would be nice, it's handy.
Comment on the last example
Real numbers can be considered identical if the same conversions are performed on them. Even seemingly identical conversions - num*0.5 and num/2.0 lead to different results. The same can be said about mirror operations. num*=num2, num/=num2. The resulting num will not equal the original num. Welcome to the world of real numbers.
In this example, 3 operations - num*=1000, num+=0.5, num/=1000 - were performed on a real number during normalization.
You can check the steps in the debugger
Very constructive explanation, thanks!
But this counterexample blows my mind.
Is this how normalization is supposed to work?
Why is it confusing?
After Slava's explanation it is not confusing, but then there is an example that makes us question the correctness of NormalizeDouble itself.