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
The need for such functionality will increase as the number of object types increases. And it will become necessary when you create objects where you can't determine the number of anchor points by their type. For example, it can be a polyline of some kind. But for now is not very critical, but it can be executed as a wish in service Desk.
For now, the best way (if you need it) is to create a switch function that will give out the number of anchor points by object type.
Just make this table (MQL5 Reference / Standard constants, enumerations and structures / Object constants / Object types) in switch. The input parameter of the function will be ObjectGetInteger(chart_id,name,OBJPROP_TYPE).
There are no hidden dangers since all the types are rigidly bound to anchor points. But if the objects with variable number of points appear, then there will be a dire need for such functionality.
Now, the most realistic way (if you need it) is to create a switch function that will give out the number of anchor points based on the object type.
I asked for a property in ObjectGet a long time ago.
it seems to me that this has to do with the logic itself in the bowels of MT5.
It probably just goes through all the points and checks them for EMPTY. And if a point has a normal digit in it, it builds.
So there is no direct relationship between object type and number of anchor points.
That's why you correctly noted that you have to make the switch yourself.
Now, the most realistic way (if you need it) is to create a switch function that will give out the number of anchor points based on the object type.
Just make this table (MQL5 Reference / Standard constants, enumerations and structures / Object constants / Object types) in switch. The input parameter of the function will be ObjectGetInteger(chart_id,name,OBJPROP_TYPE).
There are no hidden dangers since all the types are rigidly bound to anchor points. But if we get new objects with a variable number of points, we will really need this functionality.
I asked for a property in ObjectGet a long time ago.
If there will be objects with variable number of points, then such a functionality will be extremely needed.
It probably just goes through all the points and checks them for EMPTY. And if a point has a normal digit in it, it builds.
So there is no direct relationship between object type and number of anchor points.
If there are variable number of points, then there will be an extreme need for such functionality.
Yes, as I wrote above, I have it implemented via switch. It works without any problems. But the idea goes further, I want more convenience and universality.
By the way, I think it would be good to let the users create their own objects. For example, at least allow to merge standard objects into groups with a common "brand". So that it would be possible to refer to a group of objects as one. Then there would be some tricky objects like polylines, rings, torus... and so on. And even objects of some control panel could be merged. And Ctrl-B would not produce a sheet of objects, but neat names of object groups, or something similar. Also, the problem of getting 100000 events from modified objects in OnChartEven() handler would be solved, because these 100000 objects could be merged into a group and receive only one CHARTEVENT_OBJECT_CHANGE event. All in all, it would be a beauty. Of course, you can partially implement all of this through classes, but not all of it.
Lizar:
........ And Ctrl-B would give not a sheet of objects, but neat names of groups of objects, or something like that...........
....... as these 100000 objects could be combined into a group and receive just one CHARTEVENT_OBJECT_CHANGE event. All in all, a beauty.......
Dream on, don't get your hopes up.
:)
I am writing an indicator to display candlesticks for several instruments at once. After starting it and before the new bars appear, everything is displayed correctly:
But after the appearance of new bars there is a shift:
And ChartRedraw does not help. Although, if I press the right button-refresh, everything is in place. Can you tell me how to prevent the shift?
Is double price; normalized automatically in MqlTradeRequest? (which is unlikely) and if not, why is there still no normalization in the standard library? (I raised this question 9 months ago).
I got out of the situation by simply making edits in the standard library, but you know it's not the case (it's torn down when upgrading).
If i am wrong then indicate in what?
We do not do the normalisation automatically, as we are not allowed to change the trader's price so as not to be accused of arbitrariness.
You have to normalise the price yourself if you are using the calculated price. When an order is placed with net unchanged Bid/Ask prices, normalization is not necessary.
We do not do the normalisation automatically, as we are not allowed to change the trader's price so as not to be accused of arbitrariness.
You have to normalise the price yourself if you are using the calculated price. When an order is placed with net unchanged Bid/Ask prices, normalization is not necessary.
Thanks, I found out what I wanted. Even bid/ask had to be normalised in 4.
Actually, in MT4 you don't need to normalise Bid and Ask. They are always normalised by default.
If you have an example at hand, please show me.
Actually, in MT4 you don't need to normalise Bid and Ask. They are always normalised by default.
If you have an example handy, please show it to me.