Canvas - это круто! - страница 55
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ну если вспомнить Borland, то графический интерфейс собирался в визуальном редакторе, накидал макет контролов на панель, а потом прописываешь обработчики.
Если в ME была бы такая графическая возможность собирать макеты в визуальном режиме, то это на много бы упростило построение графических приложений.
Так как основная масса современных программистов, которые изучали построение GUI, привыкли(так их научили) именно к визуальному графическому редактору,
и составлять макет графического приложения на чистом коде в C-style, мало кому интересно. Так как это уже hardcore C-style.
Нужен визуальный редактор для построения графического приложения, и тогда народ потянется его изучать, а те кто работал в VS или RadStudio, те вообще быстро освоят визуальный редактор.
Вот, был уже прототип такого визуального редактора на MQL. Однако, народ горой встал против. Говорили, - не нужно это в трейдинге.
В общем, деморализовывали как могли. Потому, мне неизвестно, что на самом деле нужно для сообщества.
Полностью поддерживаю что нужно иметь способность собрать...
А вот нужно или нет - это другой вопрос.
Интересно сами разработчики рассматривают терминал как торговый инструмент или инструмент по программированию?
Возможно я ошибаюсь на текущий момент, но всегда считал что ME предоставлен именно для реализации того функционала, который требуется пользователю для торговли. Именно торговли!
Но в настоящее время глубина программирования в МЕ пошла в такие области, когда действительно нужно уметь "собирать" кубики и очень серьезно разбираться в программировании....
А к чему это приводит в итоге? Да к тому что продвинутые торговые инструменты становятся доступны только опытным программистам!
То есть если ты не программист то тебе и в торговле делать нечего... Но же абсурд...
МЕ - это всего лишь помощник по восполнению отсутствующего функционала. который бы правильнее было бы встраивать в сам терминал (различные мастера).
А по факту МЕ сейчас развивается как новая среда разработки, требующая от пользователей все больших и больших знаний.
Исходя из данного вывода визуализирующие инструменты нужны, но при этом их использование должно быть доступно и пользователям не обладающим глубокими знаниями в программировании.
Только при таком подходе они и будут востребованы.
Это только мое мнение и я его никому не навязываю.
Если рассмотреть класс CCanvas, то там порядка 20 функций рисования графических примитивов. Допустим, пользователь знает их все и знает правила и синтаксис ООП. Однако, до простейшей визуализации его данных - это слишком мало. Не говоря уже о создании простейшего элемента управления - кнопки. То есть, примитивы на канвасе рисовать относительно просто, но использовать эти примитивы в создании визуализации или GUI - во много раз сложнее. И тут не обойтись не только без знаний, - тут не обойтись без ТАЛАНТА разработчика. А многие его имеют? Это ключевая проблема.
Чтобы использовать потенциал класса Канвас нужно уметь соединять графические примитивы в более сложные объекты (элементы управления), завязывать их работу на событийной модели, прописывать связи с функциями... Либо, конвертировать цифровые данные в различные графические кривые... Это работа для талантливых и очень трудолюбивых пользователей. По сути - не пользователей, а разработчиков.
Вот, был уже прототип такого визуального редактора на MQL. Однако, народ горой встал против. Говорили, - не нужно это в трейдинге.
В общем, деморализовывали как могли. Потому, мне неизвестно, что на самом деле нужно для сообщества.
Вах, так и прототип имеется.
Так может разработчикам пересмотреть недалёкие взгляды сообщества? И возобновить план разработки визуального режима.
Как то странно конечно, что деморализовали по сути очень востребованные возможности.
Ведь сейчас мало где учат собирать графический интерфейс в C-style, если вообще этому ещё учат.
Сейчас же всех учат работать в IDE с визуальным режимом, а так как MT5 давно уже вышел за рамки только торговой платформы,
то визуальный режим построения графических приложений был бы очень востребован.
Если честно я в шоке, что разработчики прислушались к недалёким взглядам, кто был против.
Если рассмотреть класс CCanvas, то там порядка 20 функций рисования графических примитивов. Допустим, пользователь знает их все и знает правила и синтаксис ООП. Однако, до простейшей визуализации его данных - это слишком мало. Не говоря уже о создании простейшего элемента управления - кнопки. То есть, примитивы на канвасе рисовать относительно просто, но использовать эти примитивы в создании визуализации или GUI - во много раз сложнее. И тут не обойтись не только без знаний, - тут не обойтись без ТАЛАНТА разработчика. А многие его имеют? Это ключевая проблема.
Чтобы использовать потенциал класса Канвас нужно уметь соединять графические примитивы в более сложные объекты (элементы управления), завязывать их работу на событийной модели, прописывать связи с функциями... Либо, конвертировать цифровые данные в различные графические кривые... Это работа для талантливых и очень трудолюбивых пользователей. По сути - не пользователей, а разработчиков.
Peter, ты говоришь правильные слова!
Так я выступаю за то, чтобы создавать такие библиотеки, которые были бы интуитивно понятны и программистам, не знакомым с ООП.
И это касается не только GUI.
В стандартной библиотеке и в библиотеке Анатолия чтобы собрать простую форму нужно голову сломать! Реально! Шаг в право или в лево от примеров и все, ничего не работает, нужно разбираться в тонкостях.
Во всех языках конечно же GUI так же построено на библиотеках, но есть одно существенно НО! Есть исходный набор элементов управления, которые на уровне ядра библиотеки полностью "связаны" между собой, все базовые обработчики событий "прокинуты", осталось только подписаться на них если требуется изменить поведение или представление.
По сути архитектура стандартной библиотеки очень даже продуманная и ее можно было бы использовать в качестве основы для более продвинутой библиотеки.
Вах, так и прототип имеется.
Так может разработчикам пересмотреть недалёкие взгляды сообщества? И возобновить план разработки визуального режима.
Как то странно конечно, что деморализовали по сути очень востребованные возможности.
Ведь сейчас мало где учат собирать графический интерфейс в C-style, если вообще этому ещё учат.
Сейчас же всех учат работать в IDE с визуальным режимом, а так как MT5 давно уже вышел за рамки только торговой платформы,
то визуальный режим построения графических приложений был бы очень востребован.
Если честно я в шоке, что разработчики прислушались к недалёким взглядам, кто был против.
Удивляют немного другие факторы: индикаторы в 100% имеют визуальность, советники в 80% случаем имеют визуальность, скрипты в 20%. Как ни крути во всем есть визуальность и понимание этого лежит на поверхности. Однако идет развитие по интеграции с другими средами разработки, а то, что на поверхности....
Видимо о питоне и об sql просит каждый второй пользователь терминала.
Roman, Peter, Николай... у разработчиков терминала свое видинее, они авторы и хозяева программного продукта. Полагаю что развитие функциональности ME и терминала в целом идет на основании маркетинговых исследований.
Но поговорить нам никто не мешает :)
Удивляют немного другие факторы: индикаторы в 100% имеют визуальность, советники в 80% случаем имеют визуальность, скрипты в 20%. Как ни крути во всем есть визуальность и понимание этого лежит на поверхности. Однако идет развитие по интеграции с другими средами разработки, а то, что на поверхности....
Видимо о питоне и об sql просит каждый второй пользователь терминала.
Roman, Peter, Николай... у разработчиков терминала свое видинее, они авторы и хозяева программного продукта. Полагаю что развитие функциональности ME и терминала в целом идет на основании маркетинговых исследований.
Но поговорить нам никто не мешает :)
Все так.
Мое мнение такое: визуальный интерфейс советников позволит аккомулировать стратегии в одном приложении, что негативно скажется на маркетных продажах. Если все смогут легко создавать экспертов с динамичным набором стратегий (GUI это позволяет), то их текучая ротация в Маркете пойдет на спад, что скажется на продажах. На первое место выйдут эксперты объединяющие и меняющие стратегии внутри себя и уничтожат клоны, отличающиеся только настройками или несколькими условиями. Будет ли это хорошо для Маркета? Не знаю. Но, уровень советников вырастет и рассматривать их на витрине станет намного интересней.
Возможно, большинство пользователей желает, чтобы CCanvas, CGrafic и CCanvas3D были приложениями, выдающими требуемые визуализации, а не классами, для работы с которыми нужно знать принципы и синтаксис ООП. И не просто знать, а по сути - построить собственную систему визуализации, как это делает Николай.
Хоспадибожемой, да какой тут принцип ооп надо знать? Поставить точку и выбрать метод из списка?
Встречный вопрос: какого количества и каких именно "мощнейших" и "простейших" функций MQL из общего их числа
вполне достаточно для написания полностью работоспособного и потенциально наиболее доходного советника для любой
из основных мировых валютных пар?
А какой функции R или Питона, от которых здесь все потеряли голову, достаточно для написания?.. И посмотрите, табуретка, на которой вы сидите - подходящая ли она для того, что бы?...
Ну если вспомнить Borland, то графический интерфейс собирался в визуальном редакторе, накидал макет контролов на панель, а потом прописываешь обработчики.
Если в ME была бы такая графическая возможность собирать макеты в визуальном режиме, то это на много бы упростило построение графических приложений.
Так как основная масса современных программистов, которые изучали построение GUI, привыкли(так их научили) именно к визуальному графическому редактору,
и составлять макет графического приложения на чистом коде в C-style, мало кому интересно. Так как это уже hardcore C-style.
Нужен визуальный редактор для построения графического приложения, и тогда народ потянется его изучать, а те кто работал в VS или RadStudio, те вообще быстро освоят визуальный редактор.
Зачем они нужны здесь?
Все так.
Мое мнение такое: визуальный интерфейс советников позволит аккумулировать стратегии в одном приложении, что негативно скажется на маркетных продажах. Если все смогут легко создавать экспертов с динамичным набором стратегий (GUI это позволяет), то их текучая ротация в Маркете пойдет на спад, что скажется на продажах. На первое место выйдут эксперты объединяющие и меняющие стратегии внутри себя и уничтожат клоны, отличающиеся только настройками или несколькими условиями. Будет ли это хорошо для Маркета? Не знаю. Но, уровень советников вырастет и рассматривать их на витрине станет намного интересней.
Абсолютно надуманная проблема.
Визуальный интерфейс для сбора стратегий это лишнее, кому нужны кубики, то это в тслаб.
Да и в сети как то встречал программы для генерации mql кода, которые в визуальном режиме собирают стратегии кубиками.
Для разработки торговых стратегий и индикаторов, визуальный режим не нужен, это действительно лишнее.
А вот для модульных графических приложений, визуальный режим как вы показали в гифке, был бы кстати.