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
So, you want me to continue trashing the advantages of OOP, and everyone keeps trolling me?) But in essence you're right. The discussion has gone in the wrong direction.
But I'm not trolling. Just don't respond to trolls.
In TWS, bars are formed by time, irrespective of the arrival of a quote. If there is no quotation and it is time for a new bar, the bar appears as a dash on the price of the last quotation. In this case all indicators are drawn in the same way as in MT. All my ideas about bars come from the experience of working with TS.
If it were the same in MT, my solution would be the most effective. However, it is not...
Therefore, I will not suggest it for use anymore.
Peter, I suggest another topic for discussion, for the second time. No need to write anything, just theory.
But I'm not trolling. Trolls just don't respond.
I see. So the bar may not arrive when iBars are requested, but may arrive a moment after the request. Then it will be missed for the system. That's the point.
Then what, to be continuously accessed? - Clearly not the best solution.
But if someone needs to get a new bar as fast as possible without polling OnTimer, there are custom interrupts.
If you just rethink the concept of the bar here, everything will fall into place. Resources would be saved and the solution would be simple. In my opinion, the bar should be linked to time, not to quotes.
So there is no error in my code. There is a difference in the concept of bars between platforms.
And there is nothing to discuss here.Polymorphism in its pure form. OOP rules.
There's nothing to discuss for those who are in the know. Here's a sample story of how I came to the decision to learn at least a little bit about OOP.
It was not for nothing that I took the function of defining a new bar as an example. It is with this function that everything began. The function defining a new bar at the current TF was written a long time ago. Suddenly I needed it, too, but detecting it in a certain TF. Well, no problem. I rewrote it in half a click. But suddenly I need it only for the current TF. Why should I pass PERIOD_CURRENT to this function? No problem, I rewrote it again and now I have two functions with different names.
I don't know how many times I have to rewrite it or remember which one I should call. And when I understood that I could have several functions with one name and different input parameters, my agony was over...
It turns out that there is no error in my code. There is a difference in the concept of bars between the platforms.
By the way, if in my solution just change the frequency of filling the array and instead of pausing a minute, access once per second, then the problem can be completely solved. In this case, the load on the system is unlikely to increase. You may check it.
Replace if(Minute*Timer_frequency >= 60000) with if(Minute*Timer_frequency >= 1000).
Sorry, Pyotr, but your code is just chaos.