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
Mihail Matkovskij:
Although it is possible to bypass them, the question is why, when there are no such problems in other modern kernels?
Although the error is not critical, it's still inconvenient.
It's not an error, it's more of a notification. Some languages do not even have notifications of this kind. Something in the local scope overlapped something higher, so be it. That's how it was intended. But in some cases such a warning is rather useful.
For example, in MQL, global variables have nothing to do with it and my recommendation not to use them is also irrelevant:
Create multiple scopes:
And lo and behold, we get two warnings.
Hence the conclusion -
1) ignore such warnings
2) avoid using the same names in visibility areas below/above
3) convince Service Desk to remove this notification as useless
3) convince Service Desk to remove this notification as useless
If every idiot will convince Service Desk to remove this or that rule, because from their point of view it is useless, the language will soon degenerate into a primitive trash.
I mean, how can it not be created? Any programming language freely uses global variables and that's fine, but here the compiler swears. Although the error is not critical, it is still inconvenient.
The variable point reports the price of 1 point and is a substitute for the standard Point. The MarketInfo(EA_Symbol(), MODE_POINT) function gives the price of 1 point for any symbol. Further, the variable point can be used in any function, in the body of the EA, if it is a global variable of course. Agree that such cases cause some inconveniences quite often (if you certainly have experience in MQL programming). And although they can be avoided, but the question is why, if in other modern languages such problems simply do not exist?
Unfortunately, only experienced programmers understand the usefulness and importance of such a warning.
Well, I recommend everyone else to be glad of this level of compiler's help and fix their own errors. These are real places of potential errors and it's exactly for novice developers that it is crucial for learning.
I'd like a colour scheme. Not only in the editor, but also in other windows, so that the text and background colour can be changed.
The class member data should not be colored in the colour of instance variables when names coincide.
Several times already, when finishing the working day and closing programme windows, browsers, etc., I accidentally closed the MT5 terminal running in optimisation mode as well. Thus all results were lost. Restarting the terminal starts all over again.
Many programs when you click to close a window, they ask you if you are sure to close it and that unsaved data can be lost.
It is a good idea to do this if the terminal is being optimised.
It's not even an error, it's more of a notification. Some languages don't even have notifications of this kind. Something in a local area overlapped something in a higher level, so fine. That's how it was intended. But in some cases such a warning is rather useful.
For example, in MQL, global variables have nothing to do with it and my recommendation not to use them is also irrelevant:
Create multiple scopes:
And lo and behold, we get two warnings.
Hence the conclusion.
1) ignore such warnings
2) not make the same names in the visibility areas below/above
3) convince servicedesk to remove this notification as useless
Well, 2 variables with the same name in one scope is not good and any programmer knows it. But the problem is that this scope covers standard modules which any average programmer would not tamper with since he/she does not consider himself/herself a developer. To remove the warnings is not an option either. Not paying attention to them is also a real inconvenience because you might fail to notice important warnings.
I see 2 ways of solving the problem here.
1. Make the plugin not see the plugin program, if it's not explicitly specified
2. If developers are not willing to change syntax, introduce a rule for declaration of parameters in functions, similar to class fields, e.g. parameter names should start with i or i_ (from alphabet Input) and thus fix all parameters in standard modules
The compiler works correctly and these warnings are exceptionally correct.
There is only one way out: do not allow variable overlapping and do not try to preserve the right to make mistakes with demanding that others respect that right.
The compiler works correctly and these warnings are exceptionally correct.
There is only one way out: do not allow variable overlapping and do not try to preserve the right to make mistakes with demanding that the rest of us respect that right.