Обсуждение статьи "Создание графических интерфейсов для экспертов и индикаторов на базе .Net Framework и C#" - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Да, я все понимаю. Меня пугали, пугали C-шарпом... :)))
На самом то деле правильно пугали. Шарп достаточно не прост, если в него углубиться и пытаться что то годное накодить.
Реально показать пример использования, например, этой библиотеки?
Статья - супер!
Статья отличная !
Любой программист MQL уже может по ней взять и сделать GUI в профессиональном и стабильном редакторе. И многократно и не только в MT использовать результат своих трудов.
А если от Controller можно делать производные классы, то вообще "шоколад" - советник с контроллером будет общаться высокоуровневыми посылками ("открыт ордер №NN с опциями") контроллер отдавать в форму её сообщения ("добавь в таблицу строку с полями"). И таким образом деятельность разнесена на правильные части. И советник только торгует, а GUI отображает. И делать/изменять/вести их можно по отдельности, даже разными проектами и даже разными людьми.
Автору - респект !!
А если от Controller можно делать производные классы, то вообще "шоколад"
можно просто дописать в исходник свою функцию обмена данными и вызывать ее ;)
можно просто дописать в исходник свою функцию обмена данными и вызывать ее ;)
можно конечно..но вот таким незатейливым способом получается код-лапша и букет увядших проектов :-) ООП как раз сделан чтобы такое предотвращать
В оригинальном Controller должна сосредотачиваться "физика" общения с советником и формой. И способы делания производных.
Кстати, а как вся эта связка будет вести себя при замене формы ?
На мой взгляд весь кайф технологии - это советник продолжает работать как и работал (без перекомпиляции точно, а желательно и без остановки), а форму можно поменять.
Главное требование - советник торгует. Он с деньгами связан и трогать его надо как можно реже.
можно конечно..но вот таким незатейливым способом получается код-лапша и букет увядших проектов :-) ООП как раз сделан чтобы такое предотвращать
с точки зрения перфекциониста Вы правы на все 100, но к сожалению бывают случаи, когда при попытке добиться универсальности кода во всем, на выходе получаем идеально тормознутый результат, но будут учтены все возможные ситуации и исключения
ЗЫ: я вот только бросил датагридвью из VS2017 настраивать, чтобы не тормозил при работе с большими данными и обновлением хотя бы раз в 1 сек...все равно тупит, зато уж сколько классов в себя собрал и является образцом безупречного следования принципам ООП ;)
PS: datagridview исходник, всего 7000 строк, сколько еще подтягивает к себе дополнительного кода, даже не хочу считать
https://referencesource.microsoft.com/#system.windows.forms/winforms/managed/system/winforms/DataGridView.cs
)))
с точки зрения перфекциониста Вы правы на все 100, но к сожалению бывают случаи, когда при попытке добиться универсальности кода во всем, на выходе получаем идеально тормознутый результат, но будут учтены все возможные ситуации и исключения
ЗЫ: я вот только бросил датагридвью из VS2017 настраивать, чтобы не тормозил при работе с большими данными и обновлением хотя бы раз в 1 сек...все равно тупит, зато уж сколько классов в себя собрал и является образцом безупречного следования принципам ООП ;)
PS: datagridview исходник, всего 7000 строк, сколько еще подтягивает к себе дополнительного кода, даже не хочу считать
https://referencesource.microsoft.com/#system.windows.forms/winforms/managed/system/winforms/DataGridView.cs
)))
тут не поспоришь - в Микрософте мастера делать софт опережающий возможности железа :-)
---
отвлекаясь от топика - тут дети запросили "хотим сами сделать игрушку" и пришлось искать что-нить визуальное. Чтобы мышкой порисовать, задать простые правила не прибегая к питону/лиспу/шарпу - и чтобы сразу работало.
При всём богатстве выбора подошло только Kodu от микрософт. Классно, красиво, понятно, прям таки идеал "как должно выглядить визуальное программирование". Но оно столько всего из шарпа тянет и так тормозит...Придётся видимо покупать новый комп :-)
Здравствуйте! Отличная статья!
В связи с изложенным возник ряд вопросов:
1) Из текста статьи у меня создалось впечатление, что подобным же образом можно организовать не только графические интерфейсы, но и реализацию почти любого API, которое "не влезает" в MQL5.
2) Насколько я понимаю, с использованием платформы .Net писать программы можно на разных языках, не только на C#. В частности на C++. Мне гораздо ближе этот язык по разным причинам.
Вопрос мой в том, можно ли написать .Net библиотеку на C++ (я так понимаю с использованием C++/CLR) так, чтобы MQL5 расбирался в ее .Net коде так же как в вашем движке GuiController? Я имею ввиду чтобы #include "...dll" и без объявления импортируемых функций?
Практический пример, который меня интересует вот такой. Сейчас существуют возможности интегрирования опенсорсных библиотек по машинному обучению с VS2017, причем например TensorFlow предоставляет API и на C++ c поддержкой вычислений на GPU. Ваша статья предоставляет прекрасную возможность интегрировать C++ реализацию TensorFloW (или любой другой библиотеки машинного обучения) непосредственно в MQL5, что кажется мне очень удобным. Проблема в том, что почему то мне не удается даже пробную dll на C++ импортировать в MQL5 указанным здесь способом.
в статье указан совсем другой способ взаимодействия МТ5 с "внешним миром", Вам нужно в коде МТ5 описать сигнатуры функций С++ и вызывать как обычную dll, вот рабочий пример, я проверял месяц назад
https://www.mql5.com/ru/articles/18
ЗЫ: tensorflow c# отлично гуглится, вот готовые решения под C# https://nugetmusthaves.com/Tag/tensorflow