Errors, bugs, questions - page 1669

[fxsaber]

Does MQ5 program always automatically perform IndicatorRelease of all handles that it created after the execution is finished?

Or is it possible to run the indicator via IndicatorCreate by a script, then pass its handle through global variables for further work with the indicator?

[fxsaber]

https://www.mql5.com/ru/docs/basis/preprosessor/compilation

Constant	Type	Description
tester_indicator	string	Name of the custom indicator in the "indicator_name.ex5"format.Indicators necessary for testing are determined automatically fromiCustom() function call, if the corresponding parameter is specified as a constant string. For other cases (use of theIndicatorCreate() function or use of a non-constant string in the parameter specifying the indicator name) this property should be

IndicatorCreate - almost (no restrictions on the number of input parameters) rudiment?

[fxsaber]

IndicatrorRelease mistakenly returns true if called after iCustom+ChartIndicatorAdd. Correct.

[BlackTomcat]

fxsaber:
What's the meter?

We discussed it yesterday, page 1687. :) But it's better to read from this post on page 1686: https://www.mql5.com/ru/forum/1111/page1686#comment_2790746 By the way, the man was answering your same question. It just turns out that the scheme is like this. The request to call the indicator goes to the Terminal. I.e. the Expert Advisor or the script doesn't call the indicator directly, the terminal acts as an intermediary. The terminal checks if this indicator already exists with the specified parameters. If so, it returns the program, that has called the indicator, a handle (link) to the already existing indicator. And in its terminal subsoil it marks in the counter that there was another call of this indicator. I.e., it records how many handles were returned for this indicator. When someone makes the IndicatorRelease, it doesn't mean that others who called the same indicator with the same parameters don't need this indicator anymore. Therefore, the Terminal decreases the counter by one, but leaves the indicator active, because someone else uses it. This will continue until the counter is zeroed. When the counter is zeroed, the Terminal will permanently delete the indicator from the RAM.
If you try to create a code that will contain IndicatorRelease, but won't call the indicator itself, you won't compile it, because you have to pass a handle to IndicatorRelease, but if you don't call indicator from program, you won't get handle.

[fxsaber]

BlackTomcat:
Вчера обсуждали, страница 1687. :) Но читать лучше вот с этого сообщения на 1686-й странице: https://www.mql5.com/ru/forum/1111/page1686#comment_2790746 Кстати, человек на Ваш же вопрос отвечал. Просто получается, что схема такая. Запрос на вызов индикатора попадает в Терминал. Т.е. советник или скрипт не вызывают индикатор напрямую, терминал выступает посредником. В терминале происходит проверка, существует ли уже такой индикатор с указанными параметрами. Если да, то он возвращает программе, вызвавшей индикатор, хэндл (ссылку) на уже существующий индикатор. А в своих терминальных недрах помечает в счётчике, что был ещё один вызов на данный индикатор. Т.е. он ведёт учёт, сколько хэндлов на данный индикатор вернул. Когда кто-то делает IndicatorRelease, это не значит, что остальным, кто вызвал этот же индикатор с такими же параметрами, этот индикатор больше не нужен. Поэтому Терминал уменьшает счётчик на единицу, но оставляет индикатор активным, потому-что им ещё кто-то пользуется.

Thank you! This turns out to be a great saving.

If you try to create code, which will contain IndicatorRelease, but will not contain call of the indicator itself, I think, you won't compile it, because you will need to pass the handle to IndicatorRelease, and if the indicator hasn't been called from the program, you won't get the handle.

The handle can be passed through global variables. Therefore, it is possible to use it.

[Sergei Vladimirov]

fxsaber:

I can pass the handle through global variables. Therefore, it is quite possible to use it.

You don't have to pass it. :) Or at least don't call IndicatorRelease() for handle obtained this way. If you do so, it will be your error, not a language bug, don't you agree?

[fxsaber]

Sergei Vladimirov:
And you do not. :) Or at least do not call IndicatorRelease() for a handle obtained this way. If you do so, it will be your error, but not a bug of the language, do you agree?

And I'll write a bad tab for the free Market, which at a certain point will just go through the whole positive int range and try IndicatorRelease for each.

Such a script will cover all the Expert Advisors and indicators of the terminal that used iCustom without ChartIndicatorAdd.

[Sergei Vladimirov]

Again, that would be your deliberate action, not a language bug. Why did you write that?

By the way, this conversation started with your question about how to check the indicator handle before using it. Well, you can't check it, but at an attempt to use a handle of a closed indicator, you will get error 4807 - well, you should check it after each call of CopyBuffer(), if it returns -1.

[BlackTomcat]

fxsaber:
I can pass the handle through global variables. So it's quite possible to use it.

Um... Global variables for what? Terminal or EA? I've never worked with Terminal's variables, so I'm not going to discuss it. And as for EA's global variables, it's the main way to do it. If indicators are initialized in OnInit, but IndicatorRelease happens in OnDeinit, then only with global variables (EA) we will pass the handles.

[Sergei Vladimirov]

A100:
Execution error: 'invalid pointer access' (*)

What do you have A::a pointing to here?