У меня аналогично. Но проблема в том, что вы не получаете информацию постоянно, так как много раз событие пропускается/забывается/не происходит.
Для таких случаев у меня в этой библиотеке есть функция ChartChanged(), которая принудительно обновляет все параметры чарта. В основном её использую в режиме тестера.
В целом удалось достичь приемлемой работы, когда ускорение перевода координат пиксели XY <=> координаты цена-время осуществляется в десятки и даже сотни тысяч раз быстрее чем с использованием мегатормознутых ChartGet... и XY,... функций.
Nikolai Semko #: Для таких случаев в этой библиотеке есть функция ChartChanged(), которая принудительно обновляет все параметры графика. В основном я использую ее в режиме тестера.
В целом, мне удалось добиться приемлемой работы, когда ускорение перевода координат XY <=> цена-время происходит в десятки и даже сотни тысяч раз быстрее, чем при использовании мега-тормозных функций ChartGet.... и XY,....
Да, конечно, правильное решение. Я даже переношу все буферизованные значения в индикаторы, и ни один индикатор никогда не использует ни одной функции ChartGetWhatever. Это просто адский труд - создавать все эти обходные пути, и мне потребовались месяцы, чтобы понять, что параллельный доступ к любым значениям Chart из советника и индикаторов является причиной зависания всего терминала MT.
MQL просто очень критичен, когда он становится сложным. Это факт, и я бы очень хотел, чтобы MQ предложил сотрудничать с профессионалами вроде нас. Но это только пожелание. Некоторое время я общался с Ренатом напрямую, но с некоторых пор он просто перестал отвечать.
Очень жаль.
В долгосрочной перспективе единственный выход - это разрабатывать все возможное на C# и (неправильно) использовать MQL в качестве хоста для обмена данными и получения команд из C#. Это то, над чем я работаю в данный момент, и это самое стабильное решение. Пайпы написаны на родном C, и я могу выбирать между синхронной и асинхронной передачей. Все визуальные вещи выполняются в отдельном потоке. Забавный факт: 20 микросекунд уходит на преобразование всех данных метрики плюс всех цветов в байтовый поток, 10 микросекунд на передачу, 20 микросекунд на преобразование данных обратно в структуру на C# - но в 1.000 раз больше на выполнение ОДНОЙ функции ChartGetInteger() на MQL плюс еще столько же в таймере просто для проверки. Это огромное узкое место, и ничто в CCanvas, каким бы хорошим он ни был, не может его компенсировать.
Все, что вы можете сделать с помощью CCanvas, можно сделать и с помощью GDI, поскольку CCanvas в любом случае 1:1 имеет ту же основу. И с некоторыми хитростями, вы можете использовать функции C# Graphics GDI для записи непосредственно в тот же массив - также async в другом потоке, не отправляя сначала обратно растровое изображение.
Doerk Hilger #: В долгосрочной перспективе единственный выход - это разрабатывать все возможное на C# и (неправильно) использовать MQL в качестве хоста для обмена данными и получения команд из C#.
Я бы сказал, что в долгосрочной перспективе надо уходить от каких-либо трейдерских платформ, и писать свои торговые системы на С++ или Rust на высокопроизводительном сервере со своими коннекторами к биржам. Как это делают все высокотехнологичные хеджфонды, специализирующиеся на алгоритмическом трейдинге. А клиентскую панель управления со всей необходимой визуализацией можно делать на чем угодно. Да хоть в браузере.
А MT5, конечно же, отличная возможность для старта благодаря возможности протестировать свои торговые системы на реальных тиках и бесплатному доступу к котировкам. За что им большое спасибо!
можно использовать cairo https://cairographics.org/ , в качестве surface брать (исходный, тот-же что в Canvas) массив пикселей, формат ARGB32 и вперёд с песней..
далее пример, но через отдельную DLL. Прописывать #import на API cairo_XXX честно лень.
зато закрывается масса проблем. и даже встаёт вопрос, а нужен-ли Canvas..если по готовому массиву пикселей можно рисовать нормальной стабильной, взрослой библиотекой
можно использовать cairo https://cairographics.org/ , в качестве surface брать (исходный, тот-же что в Canvas) массив пикселей, формат ARGB32 и вперёд с песней..
далее пример, но через отдельную DLL. Прописывать #import на API cairo_XXX честно лень.
MQL:
C
H
ну и результат конечно :
но подход не покатит для умирающего маркета :-)
зато закрывается масса проблем. и даже встаёт вопрос, а нужен-ли Canvas..если по готовому массиву пикселей можно рисовать нормальной стабильной, взрослой библиотекой
вообще-то целился изначально в Blend2D https://blend2d.com но для win готовых бинарных пакетов с ним нету и что-то слёту не удалось его собрать из сорцов (какие-то приколы cmake они такие)
принцип использования такой-же (то-же можно предоставить пиксельный массив и по нему загоняться), но B2D более оптимизирован чем cairo и он многопоточный.
если на след.выходных руки дойдут - расскажу как с ним.
Реter Konow #: Через ресурс можно передавать большой обьем информации из тестера в советник на графике и торговать с помощью панели руками тоже. Система безусловно более сложная чем проверка состояний кнопок "мертвой" панели в тестере, но возможностей с ней на порядок больше.
Такой тандем нельзя продать на Маркете. Да и уровень покупателей там не ахти для таких сложностей. Часто встречаю жалобы типа: — Я купил советник для МТ5, но он не работает под МТ4, как это исправить?
можно использовать cairo https://cairographics.org/ , в качестве surface брать (исходный, тот-же что в Canvas) массив пикселей, формат ARGB32 и вперёд с песней..
далее пример, но через отдельную DLL. Прописывать #import на API cairo_XXX честно лень.
MQL:
C
H
ну и результат конечно :
но подход не покатит для умирающего маркета :-)
зато закрывается масса проблем. и даже встаёт вопрос, а нужен-ли Canvas..если по готовому массиву пикселей можно рисовать нормальной стабильной, взрослой библиотекой
и без внешней доп.DLL, исключительно API cairographics.org
Ну почему же нельзя, можно. Ведь это один и тот же советник, просто устанавливается одновременно на график и в тестер. На графике его панель активна, а в тестере нет. Советник с графика пишет указания открыть/закрыть ордер в ресурс, который затем читает советник в тестере и ставит/удаляет ордер. Где то на форуме я выкладывал видео работы такого тандема (или выкладывал Папков которому я его делал, не помню). В том видео показано управление торговлей в тестере через панель на графике МТ4. Может потом найду.
Ну почему же нельзя, можно. Ведь это один и тот же советник, просто устанавливается одновременно на график и в тестер. На графике его панель активна, а в тестере нет. Советник с графика пишет указания открыть/закрыть ордер в ресурс, который затем читает советник в тестере и ставит/удаляет ордер. Где то на форуме я выкладывал видео работы такого тандема (или выкладывал Папков которому я его делал, не помню). В том видео показано управление торговлей в тестере через панель на графике МТ4. Может потом найду.
Если один и тот же, то да, как-то не подумал )) Но предвижу массу проблем с пользователями, у большинства уровень ниже плинтуса.
Я уже давно реализовал это в библиотеке iCanvas.
один экземпляр оконной структуры W автоматически заполняется при каждом событии CHARTEVENT_CHART_CHANGE
.
У меня аналогично. Но проблема в том, что вы не получаете информацию постоянно, так как много раз событие пропускается/забывается/не происходит.
У меня аналогично. Но проблема в том, что вы не получаете информацию постоянно, так как много раз событие пропускается/забывается/не происходит.
Для таких случаев в этой библиотеке есть функция ChartChanged(), которая принудительно обновляет все параметры графика. В основном я использую ее в режиме тестера.
Да, конечно, правильное решение. Я даже переношу все буферизованные значения в индикаторы, и ни один индикатор никогда не использует ни одной функции ChartGetWhatever. Это просто адский труд - создавать все эти обходные пути, и мне потребовались месяцы, чтобы понять, что параллельный доступ к любым значениям Chart из советника и индикаторов является причиной зависания всего терминала MT.
Очень жаль.MQL просто очень критичен, когда он становится сложным. Это факт, и я бы очень хотел, чтобы MQ предложил сотрудничать с профессионалами вроде нас. Но это только пожелание. Некоторое время я общался с Ренатом напрямую, но с некоторых пор он просто перестал отвечать.
В долгосрочной перспективе единственный выход - это разрабатывать все возможное на C# и (неправильно) использовать MQL в качестве хоста для обмена данными и получения команд из C#. Это то, над чем я работаю в данный момент, и это самое стабильное решение. Пайпы написаны на родном C, и я могу выбирать между синхронной и асинхронной передачей. Все визуальные вещи выполняются в отдельном потоке. Забавный факт: 20 микросекунд уходит на преобразование всех данных метрики плюс всех цветов в байтовый поток, 10 микросекунд на передачу, 20 микросекунд на преобразование данных обратно в структуру на C# - но в 1.000 раз больше на выполнение ОДНОЙ функции ChartGetInteger() на MQL плюс еще столько же в таймере просто для проверки. Это огромное узкое место, и ничто в CCanvas, каким бы хорошим он ни был, не может его компенсировать.
Все, что вы можете сделать с помощью CCanvas, можно сделать и с помощью GDI, поскольку CCanvas в любом случае 1:1 имеет ту же основу. И с некоторыми хитростями, вы можете использовать функции C# Graphics GDI для записи непосредственно в тот же массив - также async в другом потоке, не отправляя сначала обратно растровое изображение.
В долгосрочной перспективе единственный выход - это разрабатывать все возможное на C# и (неправильно) использовать MQL в качестве хоста для обмена данными и получения команд из C#.
для рисования в Canvas
можно использовать cairo https://cairographics.org/ , в качестве surface брать (исходный, тот-же что в Canvas) массив пикселей, формат ARGB32 и вперёд с песней..
далее пример, но через отдельную DLL. Прописывать #import на API cairo_XXX честно лень.
MQL:
C
H
ну и результат конечно :
но подход не покатит для умирающего маркета :-)
зато закрывается масса проблем. и даже встаёт вопрос, а нужен-ли Canvas..если по готовому массиву пикселей можно рисовать нормальной стабильной, взрослой библиотекой
для рисования в Canvas
можно использовать cairo https://cairographics.org/ , в качестве surface брать (исходный, тот-же что в Canvas) массив пикселей, формат ARGB32 и вперёд с песней..
далее пример, но через отдельную DLL. Прописывать #import на API cairo_XXX честно лень.
MQL:
C
H
ну и результат конечно :
но подход не покатит для умирающего маркета :-)
зато закрывается масса проблем. и даже встаёт вопрос, а нужен-ли Canvas..если по готовому массиву пикселей можно рисовать нормальной стабильной, взрослой библиотекой
вообще-то целился изначально в Blend2D https://blend2d.com но для win готовых бинарных пакетов с ним нету и что-то слёту не удалось его собрать из сорцов (какие-то приколы cmake они такие)
принцип использования такой-же (то-же можно предоставить пиксельный массив и по нему загоняться), но B2D более оптимизирован чем cairo и он многопоточный.
если на след.выходных руки дойдут - расскажу как с ним.
Через ресурс можно передавать большой обьем информации из тестера в советник на графике и торговать с помощью панели руками тоже. Система безусловно более сложная чем проверка состояний кнопок "мертвой" панели в тестере, но возможностей с ней на порядок больше.
Такой тандем нельзя продать на Маркете. Да и уровень покупателей там не ахти для таких сложностей. Часто встречаю жалобы типа:
— Я купил советник для МТ5, но он не работает под МТ4, как это исправить?
для рисования в Canvas
можно использовать cairo https://cairographics.org/ , в качестве surface брать (исходный, тот-же что в Canvas) массив пикселей, формат ARGB32 и вперёд с песней..
далее пример, но через отдельную DLL. Прописывать #import на API cairo_XXX честно лень.
MQL:
C
H
ну и результат конечно :
но подход не покатит для умирающего маркета :-)
зато закрывается масса проблем. и даже встаёт вопрос, а нужен-ли Canvas..если по готовому массиву пикселей можно рисовать нормальной стабильной, взрослой библиотекой
и без внешней доп.DLL, исключительно API cairographics.org
рисует :-) РАБОТАЕТ !!
Такой тандем нельзя продать на Маркете.
...
Если один и тот же, то да, как-то не подумал )) Но предвижу массу проблем с пользователями, у большинства уровень ниже плинтуса.