Создание GUI для MQL в графическом режиме. - страница 10
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Односторонним опросом из мкл, пайпами, файлами или вебзапросами.
Я уверен что это было бы просто превосходно! Тут ведь не идет речь о передаче чего либо в МТ. Саму передачу данных можно выполнить любым другим способом. Важно именно оповестить МТ о том, что нужно выполнить какое-то действие. Все точно так же как в библиотеке GUI, которую вы разработали: все колбеки выполнены именно через события.
Кстати по поводу этой библиотеки: вы планируете ее расширять и переводить полностью на канвас? То есть чтобы конечной "продукт" был не множеством объектов чарта, а одной цельной картинкой.
Ну и в разрезе рассматривания dll конечно хотелось бы иметь возможность включать dll в качестве ресурсов в МТ, чтобы не приходилось "таскать" их вместе с экспертом или индикатором.
А почему остановились на дотнете для гуя?
Ну тут вопрос на самом деле не столько в GUI. Интерфейсы то я как раз легко создаю именно средствами МТ. Это конечно немного заморочено и для расширения возможностей нужно создавать свои классы обработки, но все решаемо. С net я связался из-за невозможности реализации некоторых алгоритмов работы с интернетом. На с++ получается весьма сложно и нестабильно, даже на родном, не говоря уже об МТ. Ну а раз уж связался с net, то тогда уж и за GUI взялся, так как там все для этого готово, в отличии от МТ. Среди открытых вопросов разработки приложений на любом языки, именно на любом, так как эти вопросы не связаны именно с net: 1. Обратная связь, 2. Привязка GUI к чарту (https://www.mql5.com/ru/forum/103764)-одна из тем.
Односторонним опросом из мкл, пайпами, файлами или вебзапросами.
тут уж на ваш выбор ;-)
с точки зрения прикладников - должен быть штатный способ после вызова DLL сказать обратно в МТ "вот чего хотел, то и получи".
типичный сценарий для длительных расчётов, сетевого IO- MT вызвал DLL, DLL породила тред и в нём чё-то делается. Нужен штатный способ сказать "всё, обсчиталася" . Без этого, постоянно приходится что-то, да опрашивать из советников.
тут уж на ваш выбор ;-)
с точки зрения прикладников - должен быть штатный способ после вызова DLL сказать обратно в МТ "вот чего хотел, то и получи".
типичный сценарий для длительных расчётов, сетевого IO- MT вызвал DLL, DLL породила тред и в нём чё-то делается. Нужен штатный способ сказать "всё, обсчиталася" . Без этого, постоянно приходится что-то, да опрашивать из советников.
Поддерживаю!
Ну
Мы все можем до упора спорить о преимуществах той или иной среды разработки. Только для чего? Мы все прекрасно знаем что ни одна система разработки не является самообеспеченной, так как решает определенные конкретные задачи. А для расширения возможностей используются любые другие подключаемые компоненты, разработанные на любых других языках или средах. Нужно просто обеспечить удобное взаимодействие. Далеко ходить не будем: те же самые виндовые библиотеки, которые мы используем через импорт... с их помощью мы реализуем ту функциональность, которой не хватает. И ведь тут нельзя сказать что это реализовано чисто средствами mql. ))) Так какая разница какое внешнее приложение мы используем для расширения возможностей и достижения нужных целей? Чем самописная dll хуже виндовой?
Вот к примеру статья: https://www.mql5.com/ru/articles/364
Но ведь речь не идет о том, чтобы полностью избавиться от dll, такого просто никогда не будет, так как у МТ есть строго свои задачи. В данной статье как не крути, системные библиотеки присутствуют. Да, в отличии от самодельных эти библиотеки не нужно таскать с экспертом или индикатором...
Ну а что мешает добавить возможность компиляции dll в ресурсы инструмента?
Да, на маркет такое не выложить, так как маркет не позволяет использовать dll, но для собственной разработки это было бы на порядок удобнее.
Мы все можем до упора спорить о преимуществах той или иной среды разработки. Только для чего? Мы все прекрасно знаем что ни одна система разработки не является самообеспеченной, так как решает определенные конкретные задачи. А для расширения возможностей используются любые другие подключаемые компоненты, разработанные на любых других языках или средах. Нужно просто обеспечить удобное взаимодействие. Далеко ходить не будем: те же самые виндовые библиотеки, которые мы используем через импорт... с их помощью мы реализуем ту функциональность, которой не хватает. И ведь тут нельзя сказать что это реализовано чисто средствами mql. ))) Так какая разница какое внешнее приложение мы используем для расширения возможностей и достижения нужных целей? Чем самописная dll хуже виндовой?
Вот к примеру статья: https://www.mql5.com/ru/articles/364
Но ведь речь не идет о том, чтобы полностью избавиться от dll, такого просто никогда не будет, так как у МТ есть строго свои задачи. В данной статье как не крути, системные библиотеки присутствуют. Да, в отличии от самодельных эти библиотеки не нужно таскать с экспертом или индикатором...
Ну а что мешает добавить возможность компиляции dll в ресурсы инструмента?
Да, на маркет такое не выложить, так как маркет не позволяет использовать dll, но для собственной разработки это было бы на порядок удобнее.
Подобным мыслям и постам уж лет 10. А воз и ныне...
Если речь вести об экосистеме, тогда нужно просто закрыть использование любых импортов в МТ. Но ведь этого не делают. Ведь не просто так решили использовать импорт библиотек. Какое-то время МТ не мог работать с вебзапросами, были ограничения при работе с файлами.. все это РАСШИРЯЛОСЬ за счет импорта библиотек. Это же все очевидно и все системы так работают.Даже сейчас средствами MQL можно работать с файлами только из песочницы. Данный подход никто вроде и не оспаривает, это политика разработчика и все ее понимают и поддерживают. А коли вам нужно вылезти за пределы песочницы или обратиться к реестру для хранения данных или использовать базы данных или маппинг.. то пожалуйста используйте для этого подключаемы библиотеки. Так ведь? Все вполне логично. Для инструмента базы данных не нужны и прочее не нужно.. это все нужно только для разработчиков, поэтому и имеется язык MQL, чтобы можно было реализовывать инструменты любой функциональности. А раз есть среда разработки, то МТ уже не является вещью в себе. )) Нужно просто ... развиваться )))
Подобным мыслям и постам уж лет 10. А воз и ныне...
Как это воз и ныне там?
Все возможности для взаимодействий были и есть уже давно. Поддержка DLL вообще появилась в 2004 году.
Наши языки постоянно развиваются и становятся все мощнее и функциональнее. И экосистема мощнее, чем у кого-либо.