Ошибки в функции WindowFirstVisibleBar(). - страница 2

Новый комментарий
 
Вдогонку. Полагаю, что проблема гораздо глубже и лежит в разных методах работы при первичной загрузке индикатора и при переключении тайм-фрейма. И отнюдь не связана с работой ф-ции старт. Проблема происходит ДО этого.
 
stringo:

Мы не будем исправлять это поведение. Некоторое время назад индикаторы пересчитывались на каждый чих, при каждой перерисовке графика. Потом мы убрали эту тормозуху.

Отгадайте с трёх раз что важнее: правильная работа одной функции (предназначенной для скриптов) в одном индикаторе или экономичный пересчёт всех индикаторов?

Изначально эта функция предназначалась для скриптов, так как их можно безболезненно зацикливать. Порядок выполнения индикаторов и экспертов не предполагает безупречного выполнения функции WindowFirstVisibleBar.

А если Вы не представляете как это всё работает, добро пожаловать в документацию по MQL4. Там подробно всё описано, особенно здесь https://docs.mql4.com/ru/runtime/start

По ссылке прописные истины. Вы не ответили на вопрос.
Есть функция, которая выполняется по разному, при одинаковых по сути действиях.
Это разве правильно? Почему Вы так упираетесь с этой функцией?
Узнать, что она предназначена только для скриптов, можно только из Ваших постов.
 
Это Вы упираетесь в нежелании думать.

Когда выполняется функция? - Когда запущен индикатор на пересчёт! Если индикатор не пересчитывается, функция не вызывается.

Что раньше, пересчёт индикаторов или отрисовка графика? - Конечно пересчёт! Сначала пересчитываются все индикаторы, связанные с графиком, и только потом график перерисовывается. Значение первого видимого бара формируется только после отрисовки графика. То есть после пересчёта.

Что делает функция WindowFirstVisibleBar? - Функция берёт последнее известное значение первого видимого бара и отдаёт это значение в mql4-программу. Функция ничего не рассчитывает.

Как лучше всего ловить любые изменения, произошедшие с графиком? - Конечно же скриптом, так как его можно зациклить. Именно этим скрипт отличается от эксперта и индикатора.
Добавление объектов на график, появление новых глобальных переменных, изменение значения существующих глобальных переменных, прокрутку графика, нажатие какой-либо клавиши очень легко определяет именно зацикленный скрипт! Эксперты и индикаторы все эти изменения "заметят" только по приходу нового тика.

Можно ли зациклить эксперта или пользовательского индикатора? - Эксперта можно, индикатора - ни в коем случае! Так как эксперт работает асинхронно с графиком, в своём собственном потоке, а индикатор работает в интерфейсном потоке. И пока индикатор не пересчитается, не будет пересчитан следующий индикатор в списке (если он есть) и не будет перерисован график.

Можно ли определить, что индикатор или эксперт переинициализируются из-за смены таймфрейма графика? - Запросто. Используйте функцию UninitializeReason.
 
Как это может помочь понять: " Есть функция, которая выполняется по разному, при одинаковых по сути действиях."
Если есть случаи правильного выполнения функции WindowFirstVisibleBar, значит можно в остальных случаях сделать её выполнение правильным.
Это просто надо сделать и всё.
 
Четко и ясно, доводов лично я больше не имею:) Так как такой перехлест обходить или исправлять только себе во вред, излишняя и пустая работа, которая никчему не приведет. Zhunko думаю вам придется искать для этого другие методы о которых вы так же услышали, не зацикливайте внимание на вашем подходе, думайте:)
 
stringo:

Что делает функция WindowFirstVisibleBar? - Функция берёт последнее известное значение первого видимого бара и отдаёт это значение в mql4-программу. Функция ничего не рассчитывает.
В том то и дело, что функция берет "не последнее известное значение первого видимого бара", а непонятное значение из кеша, которое на порядок больше и приближается к значению максимального к-ва баров в окне. Может проще брать значение из тайм-фрейма до его переключения? Тем более при неизменном масштабе графика к-во свечей на разных тайм-фреймах должно быть одинаково. А потом ф-ция спокойно себе пересчитает, но не будет этого непонятного всплеска к-ва баров.
 
xnsnet:
Четко и ясно, доводов лично я больше не имею:) Так как такой перехлест обходить или исправлять только себе во вред, излишняя и пустая работа, которая никчему не приведет. Zhunko думаю вам придется искать для этого другие методы о которых вы так же услышали, не зацикливайте внимание на вашем подходе, думайте:)
Все уже придумано. Просто, если указывается на явные баги, то хочется, чтоб они были исправлены. Я уж не говорю, что можно бы и "спасибо" сказать.
 
Это не всплеск это закономерность, которую достаточно просто понять при прослеживании действий, ничего непонятного не вижу, никакого кеша тоже, к максимальному количеству не приближается. Так как ориентация на первом баре в окне, я думаю это возможно решить только если ориентироваться наоборот, на последнем баре в окне, на самом деле такое действо решило бы многие проблеммы, в том числе и эту достаточно близко к истине, но я не разработчик и я незнаю как построен графический вывод и какие проблеммы это вызовет, виднее не мне, поэтому я могу лишь прокоментировать, то что вижу. Для возможности решить эту проблемму правельно, надо знать каждую строчку исходного кода терминала, а без этого знания можно только говорить что можно решить, когда решить возможно нельзя.

Дело в том что автоскрол реализован как дополнительная возможность которая для данных запаздывает, поэтому при рассмотрение этого вопроса, более правельно, отключите автоскрол и проверьте, можно считать что автоскрола не существует для вашего кода, а только для вашего взора, но опять при приходе тика все встанет на свои места. Отрисовка делается раньше чем срабатывает автоскрол именно об этом я говорю и не о чем другом. Сначала отрисовывается текущая позиция, затем она перерисовывается на позицию указанную автоскролом, никак не иначе. Данные изменяются, но вы то эти изменения не получили, потому что ваш код уже выполнен, до перерисовки. А если автоскрол внедрить в идеологию графика а не поверх, то даже перерисовки не будет, и при смене таймфрейма, все будет четко и для кода, что тут непонятно, другой вопрос в том как это отразится на всем остальном.

Вобщем я указал тему для разработчиков, решать не мне, возможно это или не возможно. Но думается мне, что это не решит других ваших проблемм, которые и без этого останутся, поэтому по большому счету это мало чего решает.
 
xnsnet:
Четко и ясно, доводов лично я больше не имею:) Так как такой перехлест обходить или исправлять только себе во вред, излишняя и пустая работа, которая никчему не приведет. Zhunko думаю вам придется искать для этого другие методы о которых вы так же услышали, не зацикливайте внимание на вашем подходе, думайте:)
Уже сделал. 9-й пост этой темы.
Если есть в языке функция, для правильной работы, которй нужны функции API, зачем нужен такой язык или такая функция?
 

Ошибка
xnsnet : "никакого кеша тоже, к максимальному количеству не приближается. "


Ну что ж. Выкладываю AVI файл. Как говорится: "Не верь глазам своим"
Смотрите: я переключаю ТФ по возрастающей - все просто замечательно. А теперь по нисходящей и вперемешку. Что это за цифры? Кто-то может мне объяснить? И это "правильное поведение" функции? Кстати, автоскрол на это совершенно не влияет.
123
Новый комментарий
Причина обращения: