Нужно ли расширять творческое пространство алготрейдинга? - страница 22

 

В поддержку автора скажу, что GUI это не "забава" а Must HAVE в любой программе. 

Даже в эксперте, которые "должен" торговать "автоматически. 


Для этого предоставлены все возможности языка. Ведь не просто так компания MetaQuotes внедрила графику и элементы управления в терминал.

Я давно уже использую свой личный GUI для всех своих программ и считаю, что это необходимость. Мне нравится его развивать. Но я развиваю его для себя. Без кастомного использования. 


Другое дело, что на форуме 90 % это программисты, Поэтому мало кто воспринимает любую идею, как ИДЕЯ ФИКС. Поэтому есть негатив.

Для того, чтобы был позитив, необходимо оформить свой движок и показать его возможности напрямую*. Только потом спрашивать и начинать обсуждать свое творение.

P/S/ Еще когда на графике не было никаких посторонних элементов, "некоторые" делали свои GUI на wingdings, я делал на DELPHI, например, и вешал поверх графика.

Было интересно и популярно (сейчас это уже выглядит смешно......). 

Сейчас уже каждый второй может что-нибудь нарисовать. Поэтому есть большая конкуренция. И я Советую не терять время , а действовать .... 


*Выставить продукт (дать людям его пощупать) и принимать вопросы и обсуждение, багрепорт........



@Реter Konow я понимаю, как Вы живете своим проектом. У меня тоже самое. Каждый проект - это твое детище. 

Но как говорили неоднократно:

Покажите людям то, что Вы сделали. Дайте пощупать, поюзать, только потом начинайте обсуждать и принимать критику.

Придет время и тогда можно будет обсуждать "полезность" проекта. 

  

 
Vladislav Andruschenko:

В поддержку автора скажу, что GUI это не "забава" а Must HAVE в любой программе. 

Даже в эксперте, которые "должен" торговать "автоматически. 

Для этого предоставлены все возможности языка. Ведь не просто так компания MetaQuotes внедрила графику и элементы управления в терминал.

Я давно уже использую свой личный GUI для всех своих программ и считаю, что это необходимость. Мне нравится его развивать. Но я развиваю его для себя. Без кастомного использования.   

Уже лет 20 как построение GUI проблемой не являются, общедоступно, и обсуждать можно только дизайнерские решения. Из-за чего столько страданий?

Нам бы с торговлей разобраться, а ГУИ, при необходимости, вопросом не является.)

 
Реter Konow:

Дизайн был сделан по эскизам. Над разными окнами я работал разное время. Первые четыре набросал за 2 часа. Над последними работал по 3 - 4 часа. Детализация везде разная. Где то больше, где то меньше. Продолжая работать над детализацией и градиентом, можно значительно повысить уровень графики. Однако, в этом проекте я стремился протестировать подключение GUI к пользовательской программе. Это заняло основную часть времени. 

Хочу обратить внимание: GUI взаимодействует с приложением полноценно. Связь двусторонняя. При этом, я не видел исходников. Все было налажено без моего ознакомления с кодом советника. 

Для подключения используются два файла:

1. External Connection 

2. Connection Properties

Пользователь (хозяин советника) подключает файлы к советнику. Заполняет файл External Connection и компилирует советник. После этого, нажатия на кнопки, чекбоксы, перемещение ручек слайдеров, и прочие действия пользователя поступают прямиком в код советника.

Пользователь, также может управлять цветами элементов и их состояниями из своей программы. Менять цвет тела, текста и рамки любого подключенного элемента GUI. Может программно вызывать/закрывать окна, программно нажимать на кнопки или менять текст в поля ввода.

Возможности продолжают расширяться. 


Вот примеры файлов подключения:

//---------------------------------------------

Примерно 35 лет назад (в начале 80-х) была попытка внедрения подобной системы, называлась она ДИМО. Смотрелась вполне неплохо: программа состоит из модулей и обращений к отображаемым на экране формам, которые возвращали в программу новые/измененные значения переменных. Мне неизвестна информация о хотя-бы одном серьезном применении этой оболочки, хотя в то время я был в курсе основных событий. 

Посмотрел Ваши коды и понял, что никогда ими не воспользуюсь. Вы пытаетесь внедрить стандарт создания GUI пользовательских программ, не имея на то никаких предпосылок. 

Немного конструктива: попробуйте предложить пользователям Вам самому создать GUI их программ, не видя кода. Они пишут ТЗ, Вы создаете точки сопряжения прикладной программы с Вашим интерфейсом. 

 
Yuriy Asaulenko:

Уже лет 20 как построение GUI проблемой не являются, общедоступно, и обсуждать можно только дизайнерские решения. Из-за чего столько страданий?

Нам бы с торговлей разобраться, а ГУИ, при необходимости, вопросом не является.)

Именно. Торговля на первом месте. А GUI просто добавляешь, как "Must have". 
Просто, чтобы знать, что у советника внутри происходит, статистика.  

Я свой "ГИП" сделал однажды на две кнопки: быстро остановить советник и разрешить только завершить логику на текущие позиции
Потом вывел переменные, чтобы знать "на каком этапе" сейчас алгоритм, так было легче находить ошибки во время торговли. 
Потом просто самую необходимую информацию, аля плечо и маржа. 
А потом просто пошло поехало. На супердизайн не претендую (хотя стараюсь, изучаю ), делал только для практичности. 

Да и судя по опыту, ручная торговля была и есть самой популярной и многие выбирают панели для торговли. И большинство предпочитают GUI,  чем "поставил и пусть работает, а что там внутри происходит?"

Поэтому торговля торговлей, но после внедрения кнопок и возможности запуска какой то логики или скрипта с графика,  а также построение своего ГИП помогает усвоить новые программы и взвимодействовать с пользователем. 
 
Реter Konow:

Выше перечисленные возможности движка, открывают новый этап в развитии алготрейдинга. (Если это еще до кого нибудь не дошло, объясняю):

ДВИЖКИ БУДУТ ЗАБИРАТЬ ФУНКЦИОНАЛ СОВЕТНИКОВ. 

Что это значит?

Это значит:

  1. Cоветники станут легче и проще. Они будут содержать только торговую логику.
  2. Движки будут усложняться и выполнять разные функции и расчеты.

Движки будут соединяться с советниками. В этом тандеме, советники получат новые возможности и функциональную мощь.


ЗЫ. Oleg Papkov на практике познакомился с возможностями моего конструктора и движка. Он может подтвердить то, что я говорю.

Не знаю. Мне понравилось. Все, что мне надо от GUI, в советнике есть. Я уже публиковал скрины. Сейчас "вылижу" весь свой тестовый советник с GUI, покажу видео.

 
Oleg Papkov:

Не знаю. Мне понравилось. Все, что мне надо от GUI, в советнике есть. Я уже публиковал скрины. Сейчас "вылижу" весь свой тестовый советник с GUI, покажу видео.

А что с ядром? Оно отдельно висит? Если да, тогда как быть с маркетом?
 
Vladislav Andruschenko:

В поддержку автора скажу, что GUI это не "забава" а Must HAVE в любой программе. 

Даже в эксперте, которые "должен" торговать "автоматически.   

Ну не знаю...

Для отладки - куда удобнее отладчик и лог.  Для использования подобного интерфейса в целях отладки - я вижу очень ограниченное число особых редких случаев, и стоит ли из-за них огород городить, если обычный Comment или Print - отображает тоже самое, но, может быть, не в таком красивом виде ?

Внесение изменений в момент работы - крайне сомнительно. Опять же, если это эксперт - то "на один раз попробовать" гораздо разумнее просто вписать в код изменение, чем городить весь интерфейс.


Единственное реальное применение интерфейсу я вижу в ручной торговле. Там - да. Все контролы могут быть востребованы, удобство работы может реально подняться. Но вопрос - многие ли из тех участников, что способны использовать данный интерфейс, готовы торговать "руками", и имеют достаточно торгового опыта ?

 
Georgiy Merts:

Ну не знаю...

Для отладки - куда удобнее отладчик и лог.  Для использования подобного интерфейса в целях отладки - я вижу очень ограниченное число особых редких случаев, и стоит ли из-за них огород городить, если обычный Comment или Print - отображает тоже самое, но, может быть, не в таком красивом виде ?

Внесение изменений в момент работы - крайне сомнительно. Опять же, если это эксперт - то "на один раз попробовать" гораздо разумнее просто вписать в код изменение, чем городить весь интерфейс.


Единственное реальное применение интерфейсу я вижу в ручной торговле. Там - да. Все контролы могут быть востребованы, удобство работы может реально подняться. Но вопрос - многие ли из тех участников, что способны использовать данный интерфейс, готовы торговать "руками", и имеют достаточно торгового опыта ?

Про торговлю в один клик я не говорю. Это хит. 

Я говорю про ГИП любой программы. 
Куда красивее и информативнее хороший ГУИ нежели набор букв коммента (если говорить про график)
Отладка на этапе разработки окей. Но на время использования нужен GUI.  

Сделал ГУИ на все свои программы и все пользователи сказали "огромное спасибо"

Другое дело,  что слишком заряженный ГУИ имеет свойство тормозить.  Но для этого применяются правильное распределение, когда ГУИ работает только,  если основная логика не делает вычислений. В этот момент можно обновить информацию. 

В общем. Как у вас с Лигой и вы имеете свою библиотеку, в которую просто подставляете новые стратегии,  так и с GUI 

Да. И ГУИ это не только контролы,  графический интерфейс пользователя. Дружественный интерфейс. 
Я читал много про гугл дизайн. Конечно это работа не одного дня. Но там очень много интересного. 
 

Задумался над фразой "расширять творческое пространство алготрейдинга". Это получается применение алготрейдинга к чему-то другому, какое-то его необычное применение. Например использование экспертов-советников в метеорологии... геологии... Например, управление форточками в теплице, в зависимости от температуры на улице. 

А что здесь имеется ввиду?

 
Yuriy Asaulenko:

Уже лет 20 как построение GUI проблемой не являются, общедоступно, и обсуждать можно только дизайнерские решения. Из-за чего столько страданий?

Нам бы с торговлей разобраться, а ГУИ, при необходимости, вопросом не является.)

Как раз является проблемой - основной и главной. Если что-то и является проблемой в программировании, то это ГУИ и ничто другое, а вот все остальное проблемой не является.

А торговля это проблема не программирования.