Errors, bugs, questions - page 519
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
Give an example of one of the many tasks where multiple prioritisation may be required.
It does not make much sense to list examples, because there may not be many of them now, but many tasks will arise in the process of developing this or that code in the future and will accumulate as a problem and as another example. If you don't ask to implement it now you will feel the need in half a year anyway.
So far in this vein, only one, but concrete problem has been brewing: after soft drawing of scattered lines it is impossible to delete manually overlapping graphical objects in logical descending order of importance (the importance is directly related to the relative seniority of each of timeframes) right from a chart, without calling the"List of objects" combo box. I would like it this way: under any circumstances, programmatically (by setting the visual priority property to a necessary value) the objects from different TFs would be grouped among similar ones (i.e. not necessarily by overlapping, but also by squeezing between them) in ascending order of importance, so that the topmost would be the most important, and at manual parsing in reverse order one could get in order to less important. And all this would be done scientifically, with programming sequential grading via property, not with tricks like who created later and who tops it (because in tasks of graphical markup there are many cases where objects from different TFs are generated not in a strict straight order, but with a mess), which leads to chaos in the visual primacy. And even OBJPROP_ZORDER will not help here, because programmatic setting of access order to an object will only provide a priority of selection with the mouse, but the required object will often be overridden by the uppermost, but what you want to see immediately, without going deep into sub-windows like "Object Properties" etc. After all, the more pleasant it is to work with a graphical interface, the clearer it is and the less has to be done to find out something or to perform a final - purposeful - manipulation with it.
And why cannot we compare objects? The lines on different TFs have a definite price. So compare the price. If the prices are equal, then draw the most important (in your opinion) line. This will be the prioritization.
To begin with, I would like to inform you that, for example, an object such as the Vertical Line has no price. There is only the time. But if both lines have the same time and they are set from different timeframes, the line from the youngest timeframe could be set last and visually overlap the line from the older one. Of course, it is possible to name objects (for example, by adding timeframe name to the end of the object name) and then compare them, but it may help except for the search of pinned objects, and not in the order of their initial positioning.
So, for the time being there is nothing to set visibility priority simply and beautifully at will of the user and not at dictation of objective circumstances on the market, moreover at simultaneous "random" market listening to different TFs.
Can't you compare the times?
Because it does not fit, this property relates to the aspect of selecting a graphical object with the mouse, not to the order in which it is rendered.
Then I suggest writing a request to the SR, because imho the order of selection should be the same as the order of visualisation - otherwise it is completely counter-intuitive. What should be highlighted is what is on the "surface". The zorder is supposed to be there so that objects can "unbind" their priority from the creation order.
The problem, as I understand it, is that one line is blocking the other. You need prioritisation in order to bring the line that is significant (to you) to the foreground. If the times of all the lines are different, then the priority is not important, because the lines don't overlap. You are interested in the times at which the lines overlap. That's your point of counting - the times of the lines when the times are the same. Or did I misunderstand your problem?
Once again, the highlighting is fine and the priority can be set. The rendering priority is bad. And "the order of selection should match the order of rendering" is a dubious conclusion. The order of anything owes nothing to anyone by itself. It should be possible at the user's discretion to set any priority to objects that require it for easy perception/access/manipulation/etc. Maybe there's a weirdo who lives on a mezzanine and sleeps with his fins hanging down from his head - the obvious order won't work for him, but for this weirdo, there should also be a way for him to set whatever priority object he considers the most logical.
Why "again"? Don't you get it yourself? I suggested a working version, the only logical one: zorder changes the order of selection and visibility, because no one would think of selecting something that is not visible in normal conditions. If it's not obvious - go ahead and try to promote "weights", "priorities" and other missing features.
I suggested a workable option, the only logical one: zorder changes both the order of selection and visibility, because no one would think of selecting something that is not normally visible.
Cached indicators in principle do not want to be recalculated when an external parameter is changed.
Example I run the indicator with parameter A, get the data, change the parameter from A to B, the data does not change, I remove the indicator.
Run the indicator with parameter B, the data is the same as that of parameter A.
I delete indicator, close terminal, wait until process kills.
Open terminal, start indicator with parameter B at once.
I get (correct calculation for parameter B) completely different data.