Errors, bugs, questions - page 2196
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
Zoom==5
Zoom==4
Zoom==3
Zoom==2
Zoom==1
Zoom==0
Set the zoom to zero, even now you can see that in the second screenshot the bar is already tight, unlike in the first.
And what is 30 bars, give me 600!Alexei, this is the result of 1.5 hours of my work. Nothing is impossible. I have satisfied my curiosity. The fact that the bar on the second screenshot is not a problem, just add to the width of the screenshot a value that depends on the scale.
Alexei, this is the result of 1.5 hours of my work. Nothing is impossible. Further on your own, I satisfied my curiosity. The fact that the bar on the second screenshot is not a problem, just add a scale-dependent value to the width of the screenshot.
Yes it is clear that you can enter different correction factors depending on the scale, which is what I have done (not in these screenshots), but it is not convenient - not universal!
Then I would have to unpack everything and store hundreds of megabytes of unpacked stuff in memory.
Or unpack by adding up the number of lines (line - tick). Saving on memory. And then decompress again, but with parsing.
Is it possible to unpack and read on the fly? I didn't study ZIP, don't know its features.
If so, I can't think of anything except resizing with a reserve. But what's the problem with it? There is ArrayFree, and the extra memory will be freed up.
It is clear that you can enter different correction factors depending on the scale, which is what I have done (not in these screenshots), but it is not convenient - not universal!
It would be universal if we introduced coefficients that depend inversely on scale. Scale more, coefficient less. Scale smaller, coefficient larger.
Is it possible to decompress and read on the fly?
Yes, here ZIPs are unpacked into memory and parsed there too.
If so, I can't think of anything other than resize with reserve. But what's the problem with it? There is ArrayFree, and all unnecessary memory will be freed.
It's too expensive. So far I've decided to do just Reserve per million MqlTick. It's crunchy, of course.
The developers have made a wonderful optimization by presenting us with ArraySwap. We need the same ArraysConcatenate.
Zoom==5
Oh, I wonder ifChartScreenShot can take a chart shot larger than the width of the screen?
Didn't know.
It would be universal if you introduced coefficients that depend on scale exactly inversely. Scale more, coefficient less. Scale smaller, coefficient larger.
But that's if there's a proportional relationship there.... But it's not a fact that it is. Or maybe I didn't get your idea.
Oh, I wonder if ChartScreenShot can take a chart shot larger than the width of the screen?
Didn't know.
Maybe...
But that's if there's a proportional relationship there.... But it's not a fact that it is. Or maybe I didn't get your idea.
Maybe...
Alexei, it's not there... it has to be in your head. This very inverse correlation should be made.
At this point, I'm sorry, I'll leave this thread.
Alexei, it's not there... It has to be in your head. That very inverse correlation needs to be made.
At this point, I'm sorry, I'll leave this thread.
Good luck!