Errors, bugs, questions - page 3121
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
If you know it, please tell me. If you upload a new version of an existing code to CodeBase, will the prohibition to vote again be reset for the previous developers and they will be able to vote for the new version again? I highly doubt it myself, but if it were possible it would be fair to reset the previous rating in place of the new one (which hypothetically is supposed to be no lower than the previous one), since the code is developing and the new version might satisfy the voter to a greater extent, while the old rating for the old code would become invalid. (True, as the functionality grows the code grows too, so there may be new bugs and glitches, even more troublesome. Anything can happen... and the new grade may be lower, but that's fine with me).
Stop tearing your hair out over the low rating of your ...codes. If a person gives your code a score of 1, it doesn't mean it is what it is. Well, redo it at least 100 times... and all 100 times this code will be rated this way. Is that so hard to understand?
Stop tearing your hair out over the low rating of your ...codes. If a person gives your code a score of 1, it doesn't mean it is what it is. Well, redo it at least 100 times... and all 100 times this code will be rated this way. Is that so hard to understand?
Perhaps your resume reflects the reality of voting and that's sad. But I'm not sad about myself - those virtual stars can't be drunk with tea and put into my wallet, I'm frustrated with the concept of the way products are presented to new users, worrying about them specifically. Where there is no credible rating/rating, users simply won't be able to effectively search for the product they want based on the 'sort by rating' criterion. It turns out the rating system is an empty system and one is left searching for the right product by name/description rather than trusting the useless number of stars. Otherwise they'll just keep fishing out stuff... what floats on the surface (deservedly or not) and what they really need will be overlooked. I was just suggesting that this should be changed to be more thoughtful. But if no one is going to fight that reality, I wash my hands of it.
Your summary may reflect the reality of voting, and that's disappointing. But I'm not sad about myself - those virtual stars can't be drunk with tea and put in my wallet, I'm disappointed in the concept of the way products are presented to new users, worrying precisely about them. Where there is no credible rating/rating, users simply won't be able to effectively search for the product they want based on the 'sort by rating' criterion. It turns out the rating system is an empty system and one is left searching for the right product by name/description rather than trusting the useless number of stars. Otherwise they'll just keep fishing out stuff... what floats on the surface (deservedly or not) and what they really need will be overlooked. I was just suggesting that this should be changed to be more thoughtful. But if no one is going to fight that reality, I wash my hands of it.
Let's have a look at your code.
Each tick triggers access to global variables, 4 requests at a time.
It follows from this that you CANNOT use this code on your personal machine, you can use it somewhere else, where you don't spare your hard drive.
In loop in one loop during search it is necessary to call ArraySize 3 times , while there are two of them, this is an additional load on the processor, this is also undesirable, code performance drops.
DeInite delete objects in a strange way, there is nothing wrong here, but it is a bad example for beginners, if you do it normally, you should enter a prefix when creating objects anddelete them without excessive recalculations.
I give 2 points for your code.
For the work of the indicator - I do not know, I have not run it.
Objective?
Well, let's take a look at your code.
On every tick access to global variables is triggered, 4 requests at a time
It follows from this that you CANNOT use this code on your personal machine, you can use it somewhere else, where you don't spare your hard drive.
In loop in one loop during search it is necessary to call ArraySize 3 times , while there are two of them, this is an additional load on the processor, this is also undesirable, code performance drops.
DeInite delete objects in a strange way, there is nothing wrong here, but it is a bad example for beginners, if you do it normally, you should enter a prefix when creating objects anddelete them without excessive recalculations.
I give 2 points for your code.
For the work of the indicator - I do not know, I have not run it.
Objective?
1. At every tick there is a call to the GP, so at every tick, and also at every re-initialization (for example, transitions through TFs) the main and heavier code inOnCalculate() is not executed, and the indicator works faster. The calculation of new data - only with the appearance of a new low bar D1, which is much rarer, than on each tick.
2. I worked thoughtfully and thoroughly over the code, but I left some redundant comparison operations in if() because I know for sure that it won't affect the performance.
3. About the MUST not be, it's greatly exaggerated. You can download it and see for yourself: the indicator flies.
4. I did not know that the GPs are downloaded to the AF and then read from the same location every time they are accessed in a running MT5 session. I still think they are read from the LCD to RAM once when I start the terminal and live there, and the indicator accesses them in RAM, not to the LCD.
5. I do not think that ArraySize() is an expensive function. And even if it is expensive, you won't notice it in this particular code. I would probably optimize this function in my first indicator where it is used quite often, while the indicator itself is much more complex and resource-intensive.
6. In OnDeinit() I use:
where just there is removal by the " l" prefix (the names " label" and " line" were used when creating the objects.
7. You have now done what a user who has downloaded and understood the code should do. You have found the flaws - this is also part of learning MQL.
8. Bottom line: 1.) my main argument of non-ideal code of this indicator - simplicity, compactness and speed... plus perfect work; 2.) my second main argument of imperfect code - lack of even bad analogues in terms of speed and versatility (see discussion of others' originals) and availability of improvements compared to the original, which, by the way, is narrow and is not folded into compact loops in terms of large number of similarly repeated blocks.
9. In spite of point 7, you didn't really understand someone else's code. Your score of 2 is too low. I would not recommend you evaluating software products by their code yet. I won't say anything about objectivity because it's impossible to expect any objectivity from any single user. An objective estimate (rating) is possible only as a sum of estimates of several sane users and it certainly doesn't have to be necessarily high.
1. At every tick there is a reference to the GP so that at every tick, as well as at every re-initialization (for example, transitions through TFs) the entire basic and heavier code inOnCalculate() is not executed, and the indicator works faster. The calculation of new data - only with the appearance of a new low bar D1, which is much rarer, than on each tick.
2. I worked thoughtfully and thoroughly over the code, but I left some unnecessary comparison operations in if() because I know for sure that it won't affect the performance.
3. About the MUST - greatly exaggerated. You can download and see for yourself that the indicator flies.
4. I did not know that the GPs are dumped to the HDD and then read from there every time they are accessed within a running MT5 session. I still think that they are read from the HD to RAM once when I start the terminal and live there, and the indicator accesses them in RAM, not to the HD.
5. I do not think that ArraySize() is an expensive function. And even if it is expensive, you won't notice it in this particular code. I would probably optimize this function in my first indicator where it is used quite often, while the indicator itself is much more complex and resource-intensive.
6. In OnDeinit() I use:
where just there is removal by the " l" prefix (the names " label" and " line" were used when creating the objects.
7. You have now done what a user who has downloaded and understood the code should do. You have found the flaws - this is also part of learning MQL.
8. Bottom line: 1.) my main argument of non-ideal code of this indicator - simplicity, compactness and speed... 2.) my second main argument of imperfect code - the absence of analogues in terms of speed and versatility (see discussion of others' originals) and availability of improvements compared to the original, which, by the way, is narrow and is not folded into compact loops in terms of large number of similarly repeated blocks.
9. In spite of point 7, you didn't really understand someone else's code. Your score of 2 is too low. I would not recommend you evaluating software products by their code yet. I won't say anything about objectivity because you simply cannot expect objectivity from any single user. An objective estimate (rating) is possible only as a sum of estimates of some sane users and it doesn't have to be necessarily high.
Deleting by prefix is as follows: ObjectsDeleteAll(0, "pref_"); // "pref_label" and " pref_line"
Add at least the first line to OnCalculate to address on a new bar and not on every tick as it is now
Delete by prefix, it's like this: ObjectsDeleteAll(0, "pref_"); // "pref_label" and " pref_line"
Add at least if the first line to OnCalculate, so that the reference is on a new bar, and not on every tick, as it is now
By the way, concerning point 7: I have encountered errors even in the MQL5 documentation, which are not corrected for many years.
Deleting by prefix is like this: ObjectsDeleteAll(0, "pref_"); // "pref_label" and " pref_line"
Delete it the way you suggest is not reasonable because the beginning of the prefix is dynamic: either{D1}, or {W1}, or{MN1} and then comes an unchangeable prefix as " l...". You can interchange dynamic and static prefixes and safely remove them according to your version. But it is not reasonable because it is inconvenient to take information as "R1{D1}", while it is more convenient to use "{D1} R1". I thought it all through a long time ago and did exactly as I did.
There is no sensible way to delete it the way you suggest, because the beginning of the prefix is dynamic: either{D1} or {W1} or{MN1}, and then there is an unchangeable prefix as " l...". You can interchange dynamic and static prefixes and safely remove them according to your version. But it is not reasonable because it is inconvenient to take information as "R1{D1}", while it is more convenient to use "{D1} R1". I thought it all through a long time ago and did exactly as I did.
DrawTheLine("pref"+line_types[lt], StStill, yes, in principle you could do that. I explained myself dashingly above, thinking at the time about:
not about object names. The chart reads exactly what is set withOBJPROP_TEXTfor labels, but object names can be signed in a less readable way, because they are hidden and rarely read.
On the other hand, in the "List of objects" (Ctrl+b) it's better to see readable object names, so my way is more preferable. In addition to that, there are cases when object names have to be extremely long, so extra"pref_" will be completely unacceptable.Still, yes, in principle, you could do that. I explained myself dashingly above, thinking at the time about:
not about object names. The chart reads exactly what is set withOBJPROP_TEXTfor labels, but object names can be signed less legible, because they are hidden and rarely read.
On the other hand, in the "List of objects" (Ctrl+b) it is desirable to see readable object names, so my version is still preferable. In addition to that, there are cases when object names have to be extremely long, so extra"pref_" will be completely unacceptable.and if someone will still have a program with graphical objects, your kind of prefix "l" < where just delete by prefix " l" (the names "label" and "line" were used when objects were created >
Will kill all objects beginning with"l" in a third party program. This is not a good solution