Mihail Matkovskij #: Но выбор всегда должен зависеть от поставленной задачи...
Забыл сказать. Использование Канваса ещё очень удобно в роботах, где нужно вывести рассчётные значения в чарт, а индикаторных буферов как известно нет под рукой. Тогда вывести значения либо сигналы можно только с помощью Канваса, если их достаточно много (не 2-3 сигнала, которые можно вывести с помощью графических объектов).
Боже, какие ж не удобные эти буферные индикаторы. Жуть. С канвасным рисованием все гораздо проще, меньше кода, нагляднее, универсальнее и полная свобода действий.
Универсальность канваса заканчивается, когда его значения нужно получить из другого советника/индикатора.
Универсальность канваса заканчивается, когда его значения нужно получить из другого советника/индикатора.
Или ты уже нашел решение и этому? )
А какие проблемы, Андрей? Формируешь структуру данных или массив структур хоть в советнике, хоть в индикаторе, и отправляешь ее в ресурс. А на приемной стороне считываешь эту структуру или массив структур. Даже более удобнее получается, так как имеешь дело с именами и разными типами данных нужных размеров, а не пронумерованными double массивами на всю длину котировок. Если это индикатор для маркета, но необходимо предоставить покупателям класс, который считывает данные с ресурса. Клиенту нужно только добавить инклуд и объявить экземпляр класса. Может еще вызвать методы из OnTimer и OnTick. И тогда этот экземпляр класса будет всегда иметь актуальные данные считываемого индикатора в виде удобно читамой структуры или массива структур.
Формируешь структуру данных или массив структур хоть в советнике, хоть в индикаторе, и отправляешь ее в ресурс.
Канвас сам по себе работает с графическим ресурсом (OBJ_BITMAP_LABEL/ OBJ_BITMAP). Так что остается сообщить имя ресурса в другое приложение и оно легко получит доступ к пикселям. Также нужно будет передать формат пикселя. И можно хоть читать пиксели хоть менять их с помощью другого CCanvas. В нем есть метод CCanvas::Attach для присоединение его к существующему ресурсу.
А какие проблемы, Андрей? Формируешь структуру данных или массив структур
Ни каких проблем! Просто лишние телодвижения, о них и говорю.
Любой буферный индикатор может быть прочитан любым другим индикатором или советником, а для канваса нужна кастумная прослойка.
Например, у меня есть советник, который получает список запущенных индикаторов, а потом создает их на указанном списке инструментов/ТФ и потом собирает с них сигналы (и шлет в телеграм). Так вот любой буферный индикатор можно просто запустить на чарте, и он будет подхвачен автоматом. А канвас-индикатор придется подключать вручную, а потом и всю остальную работу вручную прописывать.
Нужно унифицировать работу с канвас-индикаторами. И, боюсь, что в результате такой унификации получатся ... буферные индикаторы ))
Ни каких проблем! Просто лишние телодвижения, о них и говорю.
Любой буферный индикатор может быть прочитан любым другим индикатором или советником, а для канваса нужна кастумная прослойка.
Например, у меня есть советник, который получает список запущенных индикаторов, а потом создает их на указанном списке инструментов/ТФ и потом собирает с них сигналы (и шлет в телеграм). Так вот любой буферный индикатор можно просто запустить на чарте, и он будет подхвачен автоматом. А канвас-индикатор придется подключать вручную, а потом и всю остальную работу вручную прописывать.
Нужно унифицировать работу с канвас-индикаторами. И, боюсь, что в результате такой унификации получатся ... буферные индикаторы ))
Я говорю о расширении возможностей, в том числе использования одних классов для визуализации, как в индикаторах, так и в экспертах. В индикаторах, конечно же, всегда остаётся буферный способ передачи и никто не запрещает его использовать в случае чистого канваса.
И, кстати, я уже реализовывал гибридный способ передачи, когда в одном буфере передается массив структур через юнион. Хоть и нужна дополнительная надстройка на приемной стороне, но, во-первых, она не сложная, а во-вторых, это делает работу с данными другого индикатора для пользователя более простой и удобной благодаря структурам, а не массивам double. Пользователям это точно понравится.
Канвас сам по себе работает с графическим ресурсом (OBJ_BITMAP_LABEL/ OBJ_BITMAP). Так что остается сообщить имя ресурса в другое приложение и оно легко получит доступ к пикселям. Также нужно будет передать формат пикселя. И можно хоть читать пиксели хоть менять их с помощью другого CCanvas. В нем есть метод CCanvas::Attach для присоединение его к существующему ресурсу.
Вряд ли будет стоять задача передачи графики, ведь она часто синхронизирована с барами и ценой другого окна, и является интегрированной с Event моделью.
Более того, я думаю что графический ресурс даже не будет сформирован если окна индикатора не существует или оно не активно.
Если окна с индикатором не существует, то только остаётся способ через iCustom с использованием буфера или буферов. Но, как я уже говорил, можно структуру или массив структур вкладывать в эти буферы.
Более того, я думаю что графический ресурс даже не будет сформирован если окна индикатора не существует или оно не активно.
Интересно, в каких случаях если индикатор запущен а его окна не существует? А когда окно неактивно (пользователь переключился на другой чарт или свернул его), то что ресурс выгружается из памяти, попросту удаляется?
Но, как я уже говорил, можно структуру или массив структур вкладывать в эти буферы.
Здесь пожалуй соглашусь. Мне приходилось создавать мультизадачного робота. Первый экземпляр приложения создает задачи и создает чарты для них, затем применяет специальный шаблон с тем же роботом. Далее первый робот создает задачи, а роботы созданные автоматом их выполняют. Передача данных осуществляется через ресурсы. Туда передаются строки числа и структуры. Здесь на сайте есть пример передачи данных по http (если мне не изменяет память). Но там сначала идут данные о структурах, их размерах и типах, а потом сами данные. В своём эксперте я решил сделать проще, передал строки и числа через массив uchar-ов в виде строк, что в разы упростило чтение/запись. А вот в буферы индикаторов как-то не доводилось записывать байты и читать их оттуда. Но уже вижу один недостаток данного способа, это ограниченность байтов количеством баров индикатора. Хотя, в каждой ячейке массива по 8 байт. Может быть и не такой уж большой недостаток. Кто знает...
Но выбор всегда должен зависеть от поставленной задачи...
Забыл сказать. Использование Канваса ещё очень удобно в роботах, где нужно вывести рассчётные значения в чарт, а индикаторных буферов как известно нет под рукой. Тогда вывести значения либо сигналы можно только с помощью Канваса, если их достаточно много (не 2-3 сигнала, которые можно вывести с помощью графических объектов).
Боже, какие ж не удобные эти буферные индикаторы. Жуть.
С канвасным рисованием все гораздо проще, меньше кода, нагляднее, универсальнее и полная свобода действий.
Универсальность канваса заканчивается, когда его значения нужно получить из другого советника/индикатора.
Или ты уже нашел решение и этому? )
Универсальность канваса заканчивается, когда его значения нужно получить из другого советника/индикатора.
Или ты уже нашел решение и этому? )
А какие проблемы, Андрей?
Формируешь структуру данных или массив структур хоть в советнике, хоть в индикаторе, и отправляешь ее в ресурс.
А на приемной стороне считываешь эту структуру или массив структур.
Даже более удобнее получается, так как имеешь дело с именами и разными типами данных нужных размеров, а не пронумерованными double массивами на всю длину котировок.
Если это индикатор для маркета, но необходимо предоставить покупателям класс, который считывает данные с ресурса.
Клиенту нужно только добавить инклуд и объявить экземпляр класса. Может еще вызвать методы из OnTimer и OnTick. И тогда этот экземпляр класса будет всегда иметь актуальные данные считываемого индикатора в виде удобно читамой структуры или массива структур.
Формируешь структуру данных или массив структур хоть в советнике, хоть в индикаторе, и отправляешь ее в ресурс.
Канвас сам по себе работает с графическим ресурсом (OBJ_BITMAP_LABEL/ OBJ_BITMAP). Так что остается сообщить имя ресурса в другое приложение и оно легко получит доступ к пикселям. Также нужно будет передать формат пикселя. И можно хоть читать пиксели хоть менять их с помощью другого CCanvas. В нем есть метод CCanvas::Attach для присоединение его к существующему ресурсу.
А какие проблемы, Андрей?
Формируешь структуру данных или массив структур
Ни каких проблем! Просто лишние телодвижения, о них и говорю.
Любой буферный индикатор может быть прочитан любым другим индикатором или советником, а для канваса нужна кастумная прослойка.
Например, у меня есть советник, который получает список запущенных индикаторов, а потом создает их на указанном списке инструментов/ТФ и потом собирает с них сигналы (и шлет в телеграм). Так вот любой буферный индикатор можно просто запустить на чарте, и он будет подхвачен автоматом. А канвас-индикатор придется подключать вручную, а потом и всю остальную работу вручную прописывать.
Нужно унифицировать работу с канвас-индикаторами. И, боюсь, что в результате такой унификации получатся ... буферные индикаторы ))
А какие проблемы, Андрей?
короче не нашел и даже не искал
Ни каких проблем! Просто лишние телодвижения, о них и говорю.
Любой буферный индикатор может быть прочитан любым другим индикатором или советником, а для канваса нужна кастумная прослойка.
Например, у меня есть советник, который получает список запущенных индикаторов, а потом создает их на указанном списке инструментов/ТФ и потом собирает с них сигналы (и шлет в телеграм). Так вот любой буферный индикатор можно просто запустить на чарте, и он будет подхвачен автоматом. А канвас-индикатор придется подключать вручную, а потом и всю остальную работу вручную прописывать.
Нужно унифицировать работу с канвас-индикаторами. И, боюсь, что в результате такой унификации получатся ... буферные индикаторы ))
Канвас сам по себе работает с графическим ресурсом (OBJ_BITMAP_LABEL/ OBJ_BITMAP). Так что остается сообщить имя ресурса в другое приложение и оно легко получит доступ к пикселям. Также нужно будет передать формат пикселя. И можно хоть читать пиксели хоть менять их с помощью другого CCanvas. В нем есть метод CCanvas::Attach для присоединение его к существующему ресурсу.
короче не нашел и даже не искал
Интересно, в каких случаях если индикатор запущен а его окна не существует? А когда окно неактивно (пользователь переключился на другой чарт или свернул его), то что ресурс выгружается из памяти, попросту удаляется?
Здесь пожалуй соглашусь. Мне приходилось создавать мультизадачного робота. Первый экземпляр приложения создает задачи и создает чарты для них, затем применяет специальный шаблон с тем же роботом. Далее первый робот создает задачи, а роботы созданные автоматом их выполняют. Передача данных осуществляется через ресурсы. Туда передаются строки числа и структуры. Здесь на сайте есть пример передачи данных по http (если мне не изменяет память). Но там сначала идут данные о структурах, их размерах и типах, а потом сами данные. В своём эксперте я решил сделать проще, передал строки и числа через массив uchar-ов в виде строк, что в разы упростило чтение/запись. А вот в буферы индикаторов как-то не доводилось записывать байты и читать их оттуда. Но уже вижу один недостаток данного способа, это ограниченность байтов количеством баров индикатора. Хотя, в каждой ячейке массива по 8 байт. Может быть и не такой уж большой недостаток. Кто знает...