Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Вы пытаетесь в OnTimer (который является расчётной частью индикатора) управлять рисовательной частью индикатора.
Выставляя EMPTY_VALUE в буфера индикатора, Вы никак не нарушаете взаимосвязь расчётной и рисовательной частей.
Я специально представился своим именем Слава Стариков в сервис-деске, чтобы было понятно, что Вам напрямую отвечает реальный сотрудник, знакомый с реальным положением вещей, что не было передаточной цепочки в несколько звеньев.
Почему Вы не наезжаете на меня лично, а ставите под сомнение сразу весь сервис-деск?
Выше я уже написал, что OnTimer я выбрал лишь для наглядности. Почему вы прицепились к нему? С таким же успехом можно сделать это и OnInit. Вот привожу такой вариант кода. И заодно я тут немного сдвинул значения в индикаторных буферах. Это демонстрирует, что на самом деле вторая линия не полностью исчезает вместе с первой, а просто график в окне индикатора неправильно масштабируется. Т.е. линия индикатора оказывается за пределами видимости. Вот в данном случае на экране видна лишь часть жёлтой линии.
Если же отключать вторую линию, а первую оставить, то её график масштабируется нормально.
Т.е. буферы тут вообще ни при чём. Проблема с отрисовкой линий.
Вы пытаетесь в OnTimer (который является расчётной частью индикатора) управлять рисовательной частью индикатора.
Мне интересно как мы должны учитывать "ограничения архитектуры" если мы про них не знаем?
Вот справка, в которой ничего про ограничения не сказано, сказано только про отображение\неотображение буфера.
Справку мы постоянно дополняем. Но так как справка у нас на 10 языках, то это не всегда получается оперативно.
Конкретно по индикаторам. Во всех наших примерах выставление свойств рисовательной части индикаторов производится: 1. при загрузке индикатора из свойств, описанных ключевым словом #property indicator_XXX; 2. При помощи функции, изменяющих свойства индикатора, вызываемых из OnInit индикатора. Других примеров у нас просто-напросто нет - все эксперименты на свой страх и риск.
По сервис-деску.
Обычная процедура, если вопрос находится за рамками компетенции саппорта, заключается в буферизации общения между сотрудниками саппорта и разработчиками. Саппорт назначает на разработчика вопрос, получает ответ, запрашивает дополнительные данные (если сапорту что-то непонятно). Всё это в приватной переписке. Затем после нескольких итераций саппорт как специально обученные люди оформляет ответ разработчика по-правильному, цивильно, толерантно и без эмоций. На такие переписки между саппортом и разработчиками может объективно уйти много времени.
По поводу моего ответа.
Я прошу прощения у Алексея за мой резкий тон. В качестве оправдания скажу, что как правило такими заявками занимаются ещё и другие разработчики, когда по собственной инициативе, а когда по просьбе основного отвечающего. В данном случае аналогичная заявка была рассмотрена и решена на прошлой неделе. Так что ждите очередного обновления.
Ребята, ну как так можно тупить!
Итак, Стариков не имеет права Вам грубить, но Вы имеете право грубить остальным? Жизнь - это бумеранг, подумайте над этим.
А можно по архитектуре немного подробностей?
Я так понимаю что буфер DRAW_NONE это примерно то же самое что INDICATOR_CALCULATIONS со всеми вытекающими?
А можно по архитектуре немного подробностей?
Я так понимаю что буфер DRAW_NONE это примерно то же самое что INDICATOR_CALCULATIONS со всеми вытекающими?
Не совсем.
Значения буфера DRAW_NONE не участвуют в масштабировании окна индикатора, не участвуют в отрисовке индикатора.
НО. Показываются в окне данных.
В данном случае автор что-то путает: тратить свое время на то чтобы доказать кому-то что должно по другом работать, вместо того чтоб переписать (заняло бы мин 10) - это нужно уметь + еще и обидеться на какое-то слово. Вы в сетевых местах тоже рассказываете как людям нужно работать?
По СД: есть недочеты. Например, мой индикатор на ВПС (от MQL) вызвал крэш. Прикрепила в заявке индюк и логи. Мне ответили что не нужно использовать ДЛЛ на ВПС. Но дело было в том что индюк не использовал ДЛЛ и это можно узнать мин за 5 просто открыв его. Т.е. с заявкой даже не знакомились, а кто-то заплатил деньги за сервер+деньги депо и получил крэш. Понимаю что такие ошибки трудно отслеживать, но хотелось хотя бы рассмотрения заявок из-за которых возможны потери денег.
Конкретно по индикаторам. Во всех наших примерах выставление свойств рисовательной части индикаторов производится: 1. при загрузке индикатора из свойств, описанных ключевым словом #property indicator_XXX; 2. При помощи функции, изменяющих свойства индикатора, вызываемых из OnInit индикатора. Других примеров у нас просто-напросто нет - все эксперименты на свой страх и риск.
Как вы тогда прокомментруете мой предыдущий пост? Там всё сделано именно в OnInit, однако график отображается неправильно, как видно на скриншотах. Его часть не видна. А в общем случае он может быть весь за пределами видимости окна (такой пример я приводил в сервис-деске). Т.е. другими словами, не имеет значения откуда была вызов функции с DRAW_NONE (хоть из OnTimer, хоть из OnInit), в любом случае происходит баг c масштабированием остальных графиков. Поэкспериментируйте сами. Это уж никак нельзя назвать "ограничениями архитектуры".
А что касается настойчиво предлагаемого многими тут заполнения буфера EMPTY_VALUE, то во-первых, это не предусмотрено логикой программы. Зачем мне затирать все рассчитанные значения в буфере, если требуется лишь временно скрыть визуальное отображение графика. Потом всё это заново рассчитывать? А во-вторых, забивать гвозди микроскопом - это не решение проблемы. Есть буферы - это расчётная часть. Есть графические построения - это визуальная часть. Так вот дело касается лишь визуальной части. Для неё есть конкретный функционал, который должен работать корректно, как задумано.
Slava:
Значения буфера DRAW_NONE не участвуют в масштабировании окна индикатора
Как видим, это не соответствует действительности.
Я прошу прощения у Алексея за мой резкий тон. В качестве оправдания скажу, что как правило такими заявками занимаются ещё и другие разработчики, когда по собственной инициативе, а когда по просьбе основного отвечающего. В данном случае аналогичная заявка была рассмотрена и решена на прошлой неделе. Так что ждите очередного обновления.
Не совсем.
Значения буфера DRAW_NONE не участвуют в масштабировании окна индикатора, не участвуют в отрисовке индикатора.
НО. Показываются в окне данных.
Вопрос: Из этого следует, что буфер со значением DRAW_NONE в окне данных показывает реальные данные, но график под эти данные не масштабирует?
Итак, Стариков не имеет права Вам грубить, но Вы имеете право грубить остальным? Жизнь - это бумеранг, подумайте над этим.
Ну он то официальное лицо. И это служба поддержки, предполагающая определённую формальность в общении с клиентами, соблюдение этикета.
Однако вы меня тоже конечно извините, если я вас обидел ) Это на эмоциях было сказано. А вот службе поддержки эмоции непозволительны.