Errors, bugs, questions - page 519

 
tol64:
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.

 
papaklass:
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.

 
papaklass:
Can't you compare the times?
It's the same!
 
x100intraday:

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 CD, because imho the order of selection should coincide with the order of visualisation - otherwise it is completely unintuitive. What should be selected is what is on the "surface". The zorder is supposedly there so that objects can "unbind" their priority from the order in which they are created.
 
marketeer:
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.
Once again, you're fine with selectability, and you can set it as a priority. The rendering priority is bad. And "the order of selection should coincide with 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 flippers hanging down from his head - the obvious order won't work for him, but for this weirdo, there should also be an option to prioritize objects as he sees fit.
 
papaklass:
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?
Now everything is correct, except "highlight". Not highlighting, but specifically seeing as the top overlapping objects are discarded. For example, whentrading on Fibo Time Zones visually and manually, the trader does not need to highlight anything, he just needs to see which lines are superior and which are shallower in importance. And the indicator is a dumb one, it does not know which one should be lined up first and which one later, because critical data from timeframes comes unexpectedly, indicators and layouts are rebuilding, therefore the chart receives irregular data requiring violent ordering.
 
x100intraday:
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.

 
marketeer:

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.

It would be quite logical to assign selection priority to one property in tandem with visibility. Just as long as it is implemented.
 

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.

 
As of today 16.09.2011 I have 496 build/dated 25.08.11/ and supposedly 507 is already available - why isn't it being updated in time?