fxsaber: Where to add it and how it could at least theoretically help. This is a bug in the terminal. And it is a serious bug. I was lucky - I see in the log that the indicator works. However, there are a lot of indicators that work in the terminal without any information about them. But the question arises why the CPU is loading so much on an empty terminal?
Add it to OnCalculate() before checking whether the handle is correct. And if the flag is written - exit OnCalculate(). Of course, it will hardly stop OnCalculate()... but no actions will be performed...
Alexey Kozitsyn: Add before checking if the handle is correct in OnCalculate(). And if flag is written - exit OnCalculate(). Of course, this will hardly stop OnCalculate()... but no actions will be performed...
Let an uncontrollable number of indicators hang in the terminal, because they consume almost nothing anyway.
Karputov Vladimir: Trying to localise the problem as accurately as possible. This can greatly reduce the response time to an application to ServiceDesk.
I haven't been writing in MQL5 for a long time, I'm not a programmer. I know MQL4, and now I know MQL5 a little. Why do I encounter bugs in MT5 almost every day? In fact, almost every day a man in the street accidentally finds bugs! What is this all about, why it's so raw? No testers at all? I wouldn't lie to say that MT is starting to get annoying. And even more annoying is the realization that I can't program in anything else.
fxsaber: I haven't been writing in MQL5 for a long time, I'm not a programmer. I know MQL4, and now I know MQL5 a little. Why do I encounter bugs in MT5 almost every day? In fact, almost every day a man in the street accidentally finds bugs! What is this all about, why it's so raw? No testers at all? I wouldn't be lying to say that MT is starting to get annoying. And even more annoying is the realization that I can't program in anything else.
You can't write off every instance of an incorrect programming style as a bug. Otherwise it will be like in the fairy tale about the shepherd who shouted without reason: "Wolves, wolves." Everyone rushed to help - and it turned out that there were no wolves. But when the wolves really attacked and the shepherd called for help again, no one came to help him - everyone thought he was kidding again.
still, the parent's methods are dumped in the inheritor, which should not be dumped.
If you refuse to copy the buffer:
the indicator finishes successfully
If you don't want to copy the buffer, you don't need the handle either. Is this your way of helping developers to localise the bug?
Where to add it and how it could at least theoretically help. This is a bug in the terminal. And it is a serious bug. I was lucky - I see in the log that the indicator works. However, there are a lot of indicators that work in the terminal without any information about them. But the question arises why the CPU is loading so much on an empty terminal?
Add before checking if the handle is correct in OnCalculate(). And if flag is written - exit OnCalculate(). Of course, this will hardly stop OnCalculate()... but no actions will be performed...
Trying to localise the problem as accurately as possible. This can greatly reduce the response time to an application to ServiceDesk.
And here is the root of all evil: until the indicator buffer is calculated (until prev_calculated==0) - nothing can be done
that's how it works and the indicator is immediately unloaded.
And here is the root of all evil: until the indicator buffer is calculated (until prev_calculated!=0) - nothing can be done
that's how it works and the indicator is immediately unloaded.
I haven't been writing in MQL5 for a long time, I'm not a programmer. I know MQL4, and now I know MQL5 a little. Why do I encounter bugs in MT5 almost every day? In fact, almost every day a man in the street accidentally finds bugs! What is this all about, why it's so raw? No testers at all? I wouldn't be lying to say that MT is starting to get annoying. And even more annoying is the realization that I can't program in anything else.