Init() and DeInit() execution sequence - page 14
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
OK. The sockets are an unfortunate example.
Then let's take another one - jumping off the balcony! Does the AC forbid jumping off the balcony? - No? - then why don't you practice for adrenaline purposes?
Any goals must be achieved by sane means, otherwise the goals are irrational.
The balcony is also a bad example. Balconies have railings and even their height is regulated by the building code. But you can remove the railing from your balcony at home, you understand and will not jump off the balcony.
The balcony is also an unfortunate example. Balconies have railings and their height is regulated by the regulations. You can remove the handrail from the balcony at home. You understand and will not jump off the balcony.
You were talking about what the CC does not forbid you to do. Jumping off the balcony is not forbidden by the CC. Quickly pressing the power button on a computer is not forbidden by the CC. The AC does not prohibit a lot of things to do, but no one will do it in their right mind.
But you want to change the TF.... often. I wonder why. Just because the UK does not forbid it? - but that is a criticism, not a wish for MQ.
You were talking about what the CC doesn't forbid you to do. Jumping off the balcony is not forbidden by the CC. Quickly pressing the power button on a computer is not forbidden by the CC. The CC does not forbid a lot of things, but no one in their right mind would do them.
But you want to change the TF.... often. I wonder why! Just because the UK does not forbid it? - But that's criticism, not a wish for MQ.
Didn't write such a thing that I want to. The fact is that it can happen. Imagine in your home refrigerator, the light bulb in which when you open the door is either on or off, you need a certain speed to open the door, what would work properly. Isn't it cretinism?
I am amazed, aren't you a design engineer? Or are you the head of an amateur art group in a cultural centre? You have no understanding of basic design principles.
I didn't write such a thing that I want it to happen. The fact is, it can happen. Imagine a fridge in your home where the light bulb goes on and off when you open the door and you have to open the door at a certain speed to get it to work properly. Isn't it cretinism?
I am amazed, aren't you a design engineer? Or are you the head of an amateur art group in a cultural centre? You have no understanding of basic design principles.
You are the one who has no understanding of design principles.
There is a wonderful proverb: "Give a fool a glass ***, he will break *** and cut his hands."
I have asked you twice: why do you need to switch TFs frequently? What is the practical sense in these gestures (program actions)? I have not got an answer.
I am not going to participate in idiotic discussions of how one can break something on purpose, I am an engineer, not a terminator.
It is you who lack understanding of design principles.
There is a wonderful proverb: "Give a fool a glass ***, he will break his *** and cut his hands".
I have asked you 2 times a question: what for you may need to switch TFs frequently? What is the practical sense in these gestures (program actions). I have not got an answer.
I am not going to participate in idiotic discussions of how one can break something on purpose, I am an engineer, not a terminator.
Have you started wearing a badge of higher education?
I suggest deleting everything from post 125 onwards as not relevant to a constructive discussion of the problem of deinit and init priorities when changing TFs.
That's a waste of time, it was a very constructive and enlightening discussion.
It is you who lack understanding of design principles.
There is a wonderful proverb: "Give a fool a glass ***, he will break his *** and cut his hands".
I have asked you 2 times a question: what for you may need to switch TFs frequently? What is the practical sense in these gestures (program actions). I have not received an answer.
When you understand the principles of design it should be clear that the absence of a rake is good and presence is bad, and the analogy with the proverb is inappropriate.
Concerning questions. Firstly, why cling to the phrase about "frequent switching"? With the current implementation, frequency has no effect on the problem - it can manifest with single switching as well. And secondly, to answer in essence, for example, the same Slawa recommended calling ChartSetSymbolPeriod as a "modern" way to refresh offline charts. There is no guarantee that this know-how won't be built into a few indicators on a chart and triggered in a short period of time.
I understand that the situation is unlikely to change, but let's at least ask MQ to spell out all this lovely current logic in the help, along with all the details about the differences between EAs and indices, switches up and down by timeframe, and about the deinitialisation reason codes (in particular, the help still denies code 3 for indicators).
With an understanding of design principles, it should be clear that having no rake is good and having a rake is bad, and the analogy with the proverb is misplaced.
Regarding the questions. Firstly, why cling to the phrase about "frequent switching"? With the current implementation, frequency has no effect on the problem - it can manifest with single switching as well. And secondly, to answer in essence, for example, the same Slawa recommended calling ChartSetSymbolPeriod as a "modern" way to refresh offline charts. There's no guarantee that this know-how won't be built into a few indicators on a chart and triggered in a short period of time.
I understand that the situation is unlikely to change, but let's at least ask MQ to spell out all this lovely current logic in the help, along with all the details about the differences between EAs and indices, switches up and down by timeframe, and about the deinitialisation reason codes (in particular, the help still denies code 3 for indicators).
Frequent TF switching is the only thing that Dimitri appealed to as an argument in the sense that a fool can do. Therefore the adage is very appropriate.
The only thing I can agree with is that it needs to be documented in the reference. And especially detail what may behave differently in the same situations for different types of programs.
Frequent TF switching is the only thing to which Dmitry appealed as an argument in the sense that a fool can do. So the adage is very appropriate.
The only thing I can agree with is that it needs to be documented in the reference. And especially detail what may behave differently in the same situations for different types of programs.
Actually, I just told you how it is with init and deinit.
But in general, the engineering approach is super - whether it works or not, sometimes it does, sometimes it doesn't) - it's not a problem at all, it's not fatal.