Ошибки, баги, вопросы - страница 3125

 
Mihail Matkovskij #:
Но выбор всегда должен зависеть от поставленной задачи...

Забыл сказать. Использование Канваса ещё очень удобно в роботах, где нужно вывести рассчётные значения в чарт, а индикаторных буферов как известно нет под рукой. Тогда вывести значения либо сигналы можно только с помощью Канваса, если их достаточно много (не 2-3 сигнала, которые можно вывести с помощью графических объектов).

 
Nikolai Semko #:

Боже, какие ж не удобные эти буферные индикаторы. Жуть.
С канвасным рисованием все гораздо проще, меньше кода, нагляднее, универсальнее и полная свобода действий.

Универсальность канваса заканчивается, когда его значения нужно получить из другого советника/индикатора.

Или ты уже нашел решение и этому? )

 
Andrey Khatimlianskii #:

Универсальность канваса заканчивается, когда его значения нужно получить из другого советника/индикатора.

Или ты уже нашел решение и этому? )

А какие проблемы, Андрей?
Формируешь структуру данных или массив структур хоть в советнике, хоть в индикаторе, и отправляешь ее в ресурс.
А на приемной стороне считываешь эту структуру или массив структур. 
Даже более удобнее получается, так как имеешь дело с именами и разными типами данных нужных размеров, а не пронумерованными double массивами на всю длину котировок. 
Если это индикатор для маркета, но необходимо предоставить покупателям класс, который считывает данные с ресурса.
Клиенту нужно только добавить инклуд и объявить экземпляр класса. Может еще вызвать методы из OnTimer и OnTick. И тогда этот экземпляр класса будет всегда иметь актуальные данные считываемого индикатора в виде удобно читамой структуры или массива структур.

 
Nikolai Semko #:

Формируешь структуру данных или массив структур хоть в советнике, хоть в индикаторе, и отправляешь ее в ресурс.

Канвас сам по себе работает с графическим ресурсом (OBJ_BITMAP_LABEL/ OBJ_BITMAP). Так что остается сообщить имя ресурса в другое приложение и оно легко получит доступ к пикселям. Также нужно будет передать формат пикселя. И можно хоть читать пиксели хоть менять их с помощью другого CCanvas. В нем есть метод CCanvas::Attach для присоединение его к существующему ресурсу.

 
Nikolai Semko #:

А какие проблемы, Андрей?
Формируешь структуру данных или массив структур

Ни каких проблем! Просто лишние телодвижения, о них и говорю.

Любой буферный индикатор может быть прочитан любым другим индикатором или советником, а для канваса нужна кастумная прослойка.

Например, у меня есть советник, который получает список запущенных индикаторов, а потом создает их на указанном списке инструментов/ТФ и потом собирает с них сигналы (и шлет в телеграм). Так вот любой буферный индикатор можно просто запустить на чарте, и он будет подхвачен автоматом. А канвас-индикатор придется подключать вручную, а потом и всю остальную работу вручную прописывать.

Нужно унифицировать работу с канвас-индикаторами. И, боюсь, что в результате такой унификации получатся ... буферные индикаторы ))

 
Nikolai Semko #:

А какие проблемы, Андрей?

короче не нашел и даже не искал

 
Andrey Khatimlianskii #:

Ни каких проблем! Просто лишние телодвижения, о них и говорю.

Любой буферный индикатор может быть прочитан любым другим индикатором или советником, а для канваса нужна кастумная прослойка.

Например, у меня есть советник, который получает список запущенных индикаторов, а потом создает их на указанном списке инструментов/ТФ и потом собирает с них сигналы (и шлет в телеграм). Так вот любой буферный индикатор можно просто запустить на чарте, и он будет подхвачен автоматом. А канвас-индикатор придется подключать вручную, а потом и всю остальную работу вручную прописывать.

Нужно унифицировать работу с канвас-индикаторами. И, боюсь, что в результате такой унификации получатся ... буферные индикаторы ))

Я говорю о расширении возможностей, в том числе использования одних классов для визуализации, как в индикаторах, так и в экспертах. В индикаторах, конечно же, всегда остаётся буферный способ передачи и никто не запрещает его использовать в случае чистого канваса. 
И, кстати, я уже реализовывал гибридный способ передачи, когда в одном буфере передается массив структур через юнион. Хоть и нужна дополнительная надстройка на приемной стороне, но, во-первых, она не сложная, а во-вторых, это делает работу с данными другого индикатора для пользователя более простой и удобной благодаря структурам, а не массивам double. Пользователям это точно понравится.
 
Mihail Matkovskij #:

Канвас сам по себе работает с графическим ресурсом (OBJ_BITMAP_LABEL/ OBJ_BITMAP). Так что остается сообщить имя ресурса в другое приложение и оно легко получит доступ к пикселям. Также нужно будет передать формат пикселя. И можно хоть читать пиксели хоть менять их с помощью другого CCanvas. В нем есть метод CCanvas::Attach для присоединение его к существующему ресурсу.

Вряд ли будет стоять задача передачи графики, ведь она часто синхронизирована с барами и ценой другого окна, и является интегрированной с Event моделью.
Более того, я думаю что графический ресурс даже не будет сформирован если окна индикатора не существует или оно не активно.
Если окна с индикатором не существует, то только остаётся способ через iCustom с использованием буфера или буферов. Но, как я уже говорил, можно структуру или массив структур вкладывать в эти буферы.
 
Andrei Trukhanovich #:

короче не нашел и даже не искал

Спасибо, что доложился. 
Теперь мы в курсе, что Вы не в курсе 
 
Nikolai Semko #:
Более того, я думаю что графический ресурс даже не будет сформирован если окна индикатора не существует или оно не активно.

Интересно, в каких случаях если индикатор запущен а его окна не существует? А когда окно неактивно (пользователь переключился на другой чарт или свернул его), то что ресурс выгружается из памяти, попросту удаляется? 

Nikolai Semko #:
Но, как я уже говорил, можно структуру или массив структур вкладывать в эти буферы.

Здесь пожалуй соглашусь. Мне приходилось создавать мультизадачного робота. Первый экземпляр приложения создает задачи и создает чарты для них, затем применяет специальный шаблон с тем же роботом. Далее первый робот создает задачи, а роботы созданные автоматом их выполняют. Передача данных осуществляется через ресурсы. Туда передаются строки числа и структуры. Здесь на сайте есть пример передачи данных по http (если мне не изменяет память). Но там сначала идут данные о структурах, их размерах и типах, а потом сами данные. В своём эксперте я решил сделать проще, передал строки и числа через массив uchar-ов в виде строк, что в разы упростило чтение/запись. А вот в буферы индикаторов как-то не доводилось записывать байты и читать их оттуда. Но уже вижу один недостаток данного способа, это ограниченность байтов количеством баров индикатора. Хотя, в каждой ячейке массива по 8 байт. Может быть и не такой уж большой недостаток. Кто знает...