Мой подход. Ядро - Движок. - страница 26
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Конструкторы GUI делаются под конкретную графическую библиотеку. Если бы был конструктор GUI для MQL, он был бы здесь.
где то, вроде хабре, видел статью, кажется как "создаем конструктор GUI для Питон", вот и думал, что может кто видел мультиплатформенный GUI, куда можно дописать свой код
а так, если с нуля писать конструктор, то тогда лучше сразу на MQL
1. на Шарпе не писал никогда, не было интереса, но на Делфи лет 5 назад подключал .dll с кнопками и формами, вообще без проблем все работало, да и весь проект на Делфи писал в течении дня, причем полдня потратил на поиски почему стандартные формы не работали, а когда подключил через вызов системных Виндовских окошек все исправно работало, но и МТ4 тогда очень туговат был, притормаживал, сейчас летает
в общем нет проблем .dll подключить, синхронизироваться удобно стандартными мьютексами - запустил поток для связи с терминалом и все, дальше все само по себе - отдельно форма в .dll , отдельно МТ никто никого не ждет
ЗЫ: прошу заметить, что Делфи довольно непрактичен для создания .dll, но что было под рукой (на чем сидел тогда) то и юзал )))
2. а по сабжу,ну вот никак не пойму, почему нельзя использовать стандартные классы из поставки МТ, максимум было бы интересно унифицировать бы процесс создания графики, ну пусть это был бы универсальный include где можно было бы закомментировать не нужные кнопки/диалоги и т.п.
1. Это очень, очень дилетантский взгляд на проблему (без обид). Проект, который делается в течении дня, - это не Проект. Это маленькая задачка.
Представьте, что Вы создаете приложение, состоящее из 10-ти окон, среди которых есть большие таблицы данных, окна настроек и диалоговые окна. Вы рисуете их в Делфи. Потом создаете ДЛЛ. Потом подключаете к своему проекту на МТ.
Ваше приложение на МТ нужно подключить к GUI на Делфи через общую память. Функции подключить к элементам управления, данные, - к ячейкам таблиц. Вам нужно организовать сложное взаимодействие двух частей приложения и правильно все продумать.
Вам нужна синхронная работа и обмен значениями параметров между двумя частями - GUI и Приложением на МТ.
Еще раз: если приложение большое и серьезное (таблицы, окна настроек, диалоговые окна, древ.списки и т.д...) создать единую, слаженную и эффективную работу двух частей через ДЛЛ, - ОЧЕНЬ серьезная задача. Я это делал и знаю о чем говорю.
А Вы говорите о какой то маленькой задачке, которую можно за день решить. Это не серьезно.
2. Использовать стандартную библиотеку можно уже давно. Но вопрос в необходимых трудозатратах и получаемом результате. Какие они? Я знаю, что Анатолий использовал стандартную библиотеку, как трамплин для создания своей библиотеки. А зачем он это делал, если стандартная библиотека тоже работает? Ответ прост, - он все реализовал более качественно и пошел дальше стандартной библиотеки. НО, массовость распостронения может быть достигнута только за счет снижения трудности использования. Чем легче использовать, - тем больше будет пользователей (с учетом повышения качества разумеется).
1. Это очень, очень дилетантский взгляд на проблему (без обид). Проект, который делается в течении дня, - это не Проект. Это маленькая задачка.
Представьте, что Вы создаете приложение, состоящее из 10-ти окон, среди которых есть большие таблицы данных, окна настроек и диалоговые окна. Вы рисуете их в Делфи. Потом создаете ДЛЛ. Потом подключаете к своему проекту на МТ.
Ваше приложение на МТ нужно подключить к GUI на Делфи через общую память. Функции подключить к элементам управления, данные, - к ячейкам таблиц. Вам нужно организовать сложное взаимодействие двух частей приложения и правильно все продумать.
Вам нужна синхронная работа и обмен значениями параметров между двумя частями - GUI и Приложением на МТ.
Еще раз: если приложение большое и серьезное (таблицы, окна настроек, диалоговые окна, древ.списки и т.д...) создать единую, слаженную и эффективную работу двух частей через ДЛЛ, - ОЧЕНЬ серьезная задача. Я это делал и знаю о чем говорю.
А Вы говорите о какой то маленькой задачке, которую можно за день решить. Это не серьезно.
какие обиды? Вы просто не понимаете, что обмен данными между MT и .dll старо как мир
я делал .dll т.к. ранее не было в МТ достойной графики, мне захотелось кнопки и панель
таблицы? - ну рисуйте таблицы, элементы управления? - рисуйте.... Вы просто не можете разделить задачу, на том же Делфи много готовых компонентов, как для создания баз данных БД, так и для работы с ними
т.е. от МТ нужны всего лишь сами данные, а остальное сделает сторонняя программа, можете поверить на слово, но в том же Делфи написать работу с БД, с выводом в таблицы, графики и пр. работы на день ;)
что такое данные в МТ? = это всего лишь тик и бар, а историю нет смысла "гонять" через .dll - достаточно все в файл один раз сбросить и на сторонней программе работать с файлом
ЗЫ: недавно кто то из на форуме писал, что в современных ИТ-компаниях ценятся работники не те, кто досконально понимают код в котором работают, а те, кто в кратчайшие сроки может выполнить большой обьем заданий, т.е. нужно уметь интегрировать чужие разработки в свое задание, а не строиться каждый раз все с нуля! Не знаю Ваш основной вид деятельности, я никогда не работал программистом, но постоянно работаю в смежных областях, длительное время занимался обслуживанием промышленных контроллеров, АСУ и САУ, приходилось и дописывать программные решения и взаимодействовать с разработчиками, вот и приходилось вникать во все готовые программные решения - тут нельзя написать все с нуля ))), да и производители промышленного "железа" используют специализированные системы программирования, где Си, где SCADA, а где ассемблер, и каждый раз нужно суметь прочитать чужой код ;)
Вы предлагаете создать, на основе Вашего "движка", условно работоспособную конструкцию, которую не смогут в дальнейшем модифицировать программисты?
какие обиды? Вы просто не понимаете, что обмен данными между MT и .dll старо как мир
я делал .dll т.к. ранее не было в МТ достойной графики, мне захотелось кнопки и панель
таблицы? - ну рисуйте таблицы, элементы управления? - рисуйте.... Вы просто не можете разделить задачу, на том же Делфи много готовых компонентов, как для создания баз данных БД, так и для работы с ними
т.е. от МТ нужны всего лишь сами данные, а остальное сделает сторонняя программа, можете поверить на слово, но в том же Делфи написать работу с БД, с выводом в таблицы, графики и пр. работы на день ;)
ЗЫ: что такое данные в МТ? = это всего лишь тик и бар, а историю нет смысла "гонять" через .dll - достаточно все в файл один раз сбросить и на сторонней программе работать с файлом
Если от МТ брать только поступающие в него данные, и через ДЛЛ их передавать в приложение написанное на Делфи или С++, или C#, то это БЕЗУСЛОВНО возможно. Тогда торговое приложение будет полностью написано на другом языке программирования.
То есть, таймсерии, тестер, оптимизацию, синтетики и многое другое, нужно создавать на другом языке САМОСТОЯТЕЛЬНО.
Зачем вообще тогда нужнен MQL? Достаточно поставлять данные напрямую в стороннее приложение, а платформу использовать как передатчик событий и ордеров. И все. Но преимущества MQL, как языка торговых систем будет утеряно.
Зачем нужен MQL?
Затем, что MQL - прикладной язык, заточенный под написание торговых приложений. Это его главное преимущество. Он легок и прост. В нем есть масса готовых решений для программистов. Они их берут и используют.
У программистров есть выбор:
Очевидно, самый предпочтительный вариант - воспользоваться MQL и МТ, потому что они дают преимущества, - Тестирование, Оптимизация, Исследование(синтетики), Индикаторы, удобные функции, таймсерии... + Тех.поддержка языка на форуме.
Но у этого идеального варианта есть один серьезный недостаток: Ограниченность возможности создавать сложные приложения, из за трудности создания качественного GUI.
Эту, последнюю проблему я в большей части решил.
Поэтому, когда дело каснется практики, и Вы начнете писать серьезное приложение, Вы наверняка выберете МТ. Как и многие, многие другие.
...
Вы предлагаете создать, на основе Вашего "движка", условно работоспособную конструкцию, которую не смогут в дальнейшем модифицировать программисты?
Движок - это "носитель" того GUI который создается в моем конструкторе. Его не нужно модифицировать. Только подключить к приложению, и созданное GUI будет работать.
Еще раз: если приложение большое и серьезное (таблицы, окна настроек, диалоговые окна, древ.списки и т.д...) создать единую, слаженную и эффективную работу двух частей через ДЛЛ, - ОЧЕНЬ серьезная задача. Я это делал и знаю о чем говорю.
Кто сможет создать большое и сложное приложение, тот точно воспользуется gui-библиотекой. Что делать разработчику, если развивая свое приложение, он решит например, добавить анимацию? Вас искать и просить, или все ломать и строить заново?
И откуда вы взяли, что есть проблемы с созданием GUI. Посмотрите маркет, там много приложений с GUI.
1. Кто сможет создать большое и сложное приложение, тот точно воспользуется gui-библиотекой.
2. Что делать разработчику, если развивая свое приложение, он решит например, добавить анимацию? Вас искать и просить, или все ломать и строить заново?
3. И откуда вы взяли, что есть проблемы с созданием GUI. Посмотрите маркет, там много приложений с GUI.
1. В том то и дело. GUI - библиотека расчитана на серьезных программистов. Она не может получить массовое распостронение из за трудности использования. И какой тогда смысл? Единицы будут корпеть над библиотекой и создавать сложные приложения, а другие не смогут?
2. Пусть разработчик создает анимацию у себя в приложении. Причем здесь я? Он может вызывать эту анимацию независимо от GUI и Движка, или связать вызов своей анимации с какой нибудь кнопкой.
3. Есть всего несколько человек, чей GUI заслуживает внимания. Вы, Анатолий и может еще кто то... Остальное не дотягивает до мало-мальски серьезного уровня.
3. Есть всего несколько человек, чей GUI заслуживает внимания.
Я бы не был столь категоричен. И я говорил не о разработке gui-библиотеки, а о приложениях с gui. Так вот в маркете их много, кто используют собственные наработки, кто стандартную, а кто библиотеку от Анатолия.
1. В том то и дело. GUI - библиотека расчитана на серьезных программистов. Она не может получить массовое распостронение из за трудности использования. И какой тогда смысл? Единицы будут корпеть над библиотекой и создавать сложные приложения, а другие не смогут?
2. Пусть разработчик создает анимацию у себя в приложении. Причем здесь я? Он может вызывать эту анимацию независимо от GUI и Движка, или связать вызов своей анимации с какой нибудь кнопкой.
3. Есть всего несколько человек, чей GUI заслуживает внимания. Вы, Анатолий и может еще кто то... Остальное не дотягивает до мало-мальски серьезного уровня.
Петер, на мой взгляд, у тебя главная проблема, как раз в позиционировании проекта.
Он может быть интересен только участникам, которые имеют достаточно неплохой опыт в программировании, но при этом - предпочитают торговать руками.
Думаешь, таких много ?
Ты ж погляди - все критики твоей разработки - это люди, не занимающиеся "ручной" торговлей регулярно. Максимум - время от времени. И, раз они не глядят на твой проект, как "ручные" трейдеры - они глядят на него, как программисты. И, понятное дело, находят кучу очень сомнительных решений.
Вопрос у тебя, по-моему, должен сейчас стоять именно в поиске этой ниши (на мой взгляд, очень узкой) - программистов, предпочитающих торговать руками.
где то, вроде хабре, видел статью, кажется как "создаем конструктор GUI для Питон", вот и думал, что может кто видел мультиплатформенный GUI, куда можно дописать свой код
а так, если с нуля писать конструктор, то тогда лучше сразу на MQL
Современные GUI конструкторы (те которые "раскидывает кнопки по формочкам") довольно технологичная вещь и прицепить к ним элементы MQL не выглядит фантастичным.
Практически у всех в промежуточном виде (файл проекта, etc) лежит XML который описывает расположение и взаимоотношения элементов.
Генерация кода целевой платформы - по факту это XSLT преобразование, которое умеет делать любой кто считает себя веб-программистом :-)
Берётся например EasyAndFast (https://www.mql5.com/ru/code/19703) потому что объектная, и имеет все необходимые компоненты. (и кстати открыта и документирована в отличии от топика),
и просто пишется транслятор.
Констукторов gui-mql нет не потому что мега-сложно, а просто это не востребовано.