Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Я уже давно реализовал это в библиотеке 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
рисует :-) РАБОТАЕТ !!
Такой тандем нельзя продать на Маркете.
...
Если один и тот же, то да, как-то не подумал )) Но предвижу массу проблем с пользователями, у большинства уровень ниже плинтуса.