Мой подход. Ядро - Движок. - страница 24
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Верно.
Движок несущий GUI приложения, просто выполняет механику элементов управления (кнопок, полей ввода и т.д...).
Нажатия на кнопки, чекбоксы, ввод текста и прочие действия пользователя, прямиком передаются в приложение разработчика.
Приложение может передавать в поля и таблицы свои данные.
Все осуществляется через простой файл подключения.
А ну тогда другое дело.
Сейчас как раз к МТ NET-dll подоспели. Сделать ГУИ на C-шарп для МТ уже никаких сложностей не представляет, да и с большей функциональностью. А т.к. по любому все события идут на МТ-тиках, то и кнопочки тоже. Ну анализ прикрутить, имхо, проще к ДЛЛ, чем к Петеру.
В общем, движок Петера, если кому и пригодится, то только Маркет-продавцам, где ДЛЛ низзя.
Во первых, вы лукавите, говоря о том, что "никаких сложностей не представляет". Сделать GUI на С# можно легко, а соединить с MQL-приложением???
Покажите пример такого соединения. Это как минимум, жуткий костыль. Нужно все делать через ДЛЛ. Посылать события, принимать события...
Интерфейс взаимодействия нужно создавать самому. Сколько сил и времени займет разработка взаимосвязи GUI на шарпе, с приложением на МТ ЧЕРЕЗ ДЛЛ?
Кто будет этим заниматься, на фоне простоты моего решения? У меня уже есть интерфейс подключения. Вопрос подключения - полчаса (если несколько окон). Все очень просто. Никаких ДЛЛ.
Так что это, "умирающая" идея.
Во первых, вы лукавите, говоря о том, что "никаких сложностей не представляет". Сделать GUI на С# можно легко, а соединить с MQL-приложением???
Покажите пример такого соединения. Это как минимум, жуткий костыль. Нужно все делать через ДЛЛ. Посылать события, принимать события...
Интерфейс взаимодействия нужно создавать самому. Сколько сил и времени займет разработка взаимосвязи GUI на шарпе с приложением на МТ ЧЕРЕЗ ДЛЛ?
Кто будет этим заниматься, на фоне простоты моего решения? У меня уже есть интерфейс подключения. Вопрос подключения - полчаса (если несколько окон). Все очень просто. Никаких ДЛЛ.
Так что это, "умирающая" идея.
Все тоже самое. Никаких сложностей. Нет никакой разницы какую функцию вы вызываете - приложения или ДЛЛ. Вы видите сложности в вызове функций?
Все тоже самое. Никаких сложностей. Нет никакой разницы какую функцию вы вызываете - приложения или ДЛЛ. Вы видите сложности в вызове функций?
Нет. Дело в памяти, в которой должны синхронизироватся значения параметров. Память должна быть либо в файле, либо в общей памяти приложений в ДЛЛ (или еще где то).
Но не это главное.
ГЛАВНОЕ:
РАЗРАБОТКА ИНТЕРФЕЙСА ВЗАИМОДЕЙСТВИЯ МQL-ПРИЛОЖЕНИЯ И GUI НА ШАРПЕ НЕ СТАНДАРТИЗИРОВАНА. Каждый разработчик должен будет сам придумывать интерфейс подключения к своему GUI на Шарпе.
И зачем это будет нужно, если у меня уже все работает?
Нет. Дело в памяти, в которой должны синхронизироватся значения параметров. Память должна быть либо в файле, либо в общей памяти приложений в ДЛЛ (или еще где то).
Но не это главное.
ГЛАВНОЕ:
РАЗРАБОТКА ИНТЕРФЕЙСА ВЗАИМОДЕЙСТВИЯ МQL-ПРИЛОЖЕНИЯ И GUI НА ШАРПЕ НЕ СТАНДАРТИЗИРОВАНА. Каждый разработчик должен будет сам придумывать интерфейс подключения к своему GUI на Шарпе.
И зачем это будет нужно, если у меня уже все работает?
Вы драматизируете ситуацию.)
Вы драматизируете ситуацию.)
Ни капли. Я знаю ситуацию. Я делал взаимосвязь между приложением на МТ и на Шарпе, через ДЛЛ написанной на С++. Жуткий гемморой. Нужно работать с визуальной студией и с МТ одновременно. Потом параллельно запускать приложения.
Но главное, - формат взаимодействия частей приложения никем не разработан. Следовательно, каждый будет мучится сам.
Ни капли. Я знаю ситуацию. Я делал взаимосвязь между приложением на МТ и на Шарпе, через ДЛЛ написанной на С++. Жуткий гемморой. Нужно работать с визуальной студией и с МТ одновременно. Потом параллельно запускать приложения.
Но главное, - формат взаимодействия частей приложения никем не разработан. Следовательно, каждый будет мучится сам.
ДЛЛ - стандартный инструмент Виндовс. Взаимодействие с ДЛЛ уже давно разработано и повсеместно применяется, еще со времен ДОС. Нет там проблем вообще.
ДЛЛ - стандартный инструмент Виндовс. Взаимодействие с ДЛЛ уже давно разработано и повсеместно применяется, еще со времен ДОС. Нет там проблем вообще.
Разработано взаимодействие с ДЛЛ со стороны Шарпа. А взаимодействие МКЛ-приложения с Шарпом через ДЛЛ, - личная морока программиста.
Ему нужно организовать общую память и сделать вызовы своих функций на основе чтения флагов.
Следовательно, нужно без конца обращатся к общей памяти, которая в ДЛЛ или в файле. Ведь нет обратного вызова из Шарпа через ДЛЛ в МТ.
Разработано взаимодействие с ДЛЛ со стороны Шарпа. А взаимодействие МКЛ-приложения с Шарпом через ДЛЛ, - личная морока программиста.
Ему нужно организовать общую память и сделать вызовы своих функций на основе чтения флагов.
Следовательно, нужно без конца обращатся к общей памяти, которая в ДЛЛ или в файле. Ведь нет обратного вызова из Шарпа через ДЛЛ в МТ.
У вас и в МТ нет обратного вызова. Все делается по предопределенным в МТ событиям, которых раз, и все.
Вы все равно будете передавать в ДЛЛ события терминала, и без разницы, где вы их будете обрабатывать, в МТ или в ДЛЛ.
Даже если представить, что постоянная проверка сообщений от Шарпа со стороны МКЛ-приложения, это не накладно, то разработка формата взаимодействия - очень объемная задача.
Эта задача включает в себя следующее:
1. Придумывание организации общей памяти.
2. Реализация взаимодействия трех сторон.
3. Синхронное тестирование трех сторон (Шарп, ДЛЛ, МТ-приложение).
Очень трудозатратно.
В моем случае, пользователь получает файл и заполняет его. И подключение работает.