Создание GUI для MQL в графическом режиме. - страница 10

 
Renat Fatkhullin:
Односторонним опросом из мкл, пайпами, файлами или вебзапросами.

В обратную прямыми вызовами никак. Хотя можем добавить метод типа OnExternal с параметрами, но надо продумать канал передачи.

Это может быть:
 - коллбак с параметрами, регистрируемый в длл
 - именованный мьютекс как триггер
 - windows message для PostMessage

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

Кстати по поводу этой библиотеки: вы планируете ее расширять и переводить полностью на канвас? То есть чтобы конечной "продукт" был не множеством объектов чарта, а одной цельной картинкой. 

Ну и в разрезе рассматривания dll конечно хотелось бы иметь возможность включать dll в качестве ресурсов в МТ, чтобы не приходилось "таскать" их вместе с экспертом или индикатором.

 
Renat Fatkhullin:
А почему остановились на дотнете для гуя?

Простые формы можно элементарно делать на C++ и других языках. И не будет проблем сопряжения и потери ресурсов.

Да и на MQL5 абсолютно несложно сделать интерфейсы по родному.

Ну тут вопрос на самом деле не столько в GUI. Интерфейсы то я как раз легко создаю именно средствами МТ. Это конечно немного заморочено и для расширения возможностей нужно создавать свои классы обработки, но все решаемо. С net я связался из-за невозможности реализации некоторых алгоритмов работы с интернетом. На с++ получается весьма сложно и нестабильно, даже на родном, не говоря уже об МТ. Ну а раз уж связался с net, то тогда уж и за GUI взялся, так как там все для этого готово, в отличии от МТ. Среди открытых вопросов разработки приложений на любом языки, именно на любом, так как эти вопросы не связаны именно с net: 1. Обратная связь, 2. Привязка GUI к чарту (https://www.mql5.com/ru/forum/103764)-одна из тем. 

Как создать окно-форму в mt Dll с помощью Delphi?
Как создать окно-форму в mt Dll с помощью Delphi?
  • 2007.06.22
  • www.mql5.com
В одной из экспортируемых функций хочу создать не модальное окно-форму с помощью Делфи interface type TMTDllForm = class(TForm) private procedure W...
 
Renat Fatkhullin:
Односторонним опросом из мкл, пайпами, файлами или вебзапросами.

В обратную прямыми вызовами никак. Хотя можем добавить метод типа OnExternal с параметрами, но надо продумать канал передачи.

Это может быть:
 - коллбак с параметрами, регистрируемый в длл
 - именованный мьютекс как триггер
 - windows message для PostMessage

тут уж на ваш выбор ;-)

с точки зрения прикладников -  должен быть штатный способ после вызова DLL сказать обратно в МТ "вот чего хотел, то и получи".

типичный сценарий для длительных расчётов, сетевого IO- MT вызвал DLL, DLL породила тред и в нём чё-то делается. Нужен штатный способ сказать "всё, обсчиталася" . Без этого, постоянно приходится что-то, да опрашивать из советников.

 
Maxim Kuznetsov:

тут уж на ваш выбор ;-)

с точки зрения прикладников -  должен быть штатный способ после вызова 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. А воз и ныне...
Ренат обычно говорит про экосистему и мы не позволим...
 
Yuriy Asaulenko:
Подобным мыслям и постам уж лет 10. А воз и ныне...
Ренат обычно говорит про экосистему и мы не позволим...

Если речь вести об экосистеме, тогда нужно просто закрыть использование любых импортов в МТ. Но ведь этого не делают. Ведь не просто так решили использовать импорт библиотек. Какое-то время МТ не мог работать с вебзапросами, были ограничения при работе с файлами.. все это РАСШИРЯЛОСЬ за счет импорта библиотек. Это же все очевидно и все системы так работают.Даже сейчас средствами MQL можно работать с файлами только из песочницы. Данный подход никто вроде и не оспаривает, это политика разработчика и все ее понимают и поддерживают. А коли вам нужно вылезти за пределы песочницы или обратиться к реестру для хранения данных или использовать базы данных или маппинг.. то пожалуйста используйте для этого подключаемы библиотеки. Так ведь? Все вполне логично. Для инструмента базы данных не нужны и прочее не нужно.. это все нужно только для разработчиков, поэтому и имеется язык MQL, чтобы можно было реализовывать инструменты любой функциональности. А раз есть среда разработки, то МТ уже не является вещью в себе. )) Нужно просто ... развиваться )))

 
Yuriy Asaulenko:
Подобным мыслям и постам уж лет 10. А воз и ныне...
Ренат обычно говорит про экосистему и мы не позволим...

Как это воз и ныне там?

Все возможности для взаимодействий были и есть уже давно. Поддержка DLL вообще появилась в 2004 году.

Наши языки постоянно развиваются и становятся все мощнее и функциональнее. И экосистема мощнее, чем у кого-либо.