Обсуждение статьи "Связь с MetaTrader 5 через именованные каналы без применения DLL" - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
................
С одной стороны избавили от dll, а с другой опять же, для прикладного применения необходимы костыли на других языках программирования.
Недостаток предложенного метода заключается в том, что он подходит лишь для программистов, разрабатывающих приложения на языках отличных от MQL. ..................
Вы бы хоть название этого топика прочитали ради интереса
Уже низя. См. https://www.mql5.com/ru/forum/7806/page3
Только учтите, что это клиентская поддержка, а серверные коннекты в терминале создавать нельзя.
Уже низя. См. https://www.mql5.com/ru/forum/7806/page3
А я по тихому. Ты тока не говори никому. Тсссс.....
Эх, Вы. Разработчики так старались, клиентские коннекты приделывали, статью писали.
А Вы что? Вместо того, чтобы все бросить, изучить С и честно и открыто пользоваться всем этим хозяйством, втихаря и в глубоком подполье гоняете коннекты через dll.
Сколько (не будем показывать пальцем) не корми, а он все через dll норовит в терминале.
Нормальные герои всегда идут в обход © Н. Коростылев
Напишите свой шлюз на MQL5, отталкиваясь от примеров из вышеупомянутой статьи. А клиентские скрипты уже можете на чистом MQL писать.
Хотя, я сам не понимаю, зачем было делать такое однобокое решение. Тем, кто напишет свой сервер на С, не проблема и dll подключить, а остальным текущего функционала будет мало. Разве что dll сильно замедляет работу (в чем я сомневаюсь).
Она о том, чтобы иметь возможность подключаться из терминала к сторонним системам без применения DLL. Задача выполнена - теперь есть легкий способ подключения и полнодуплексного обмена данными.
Жалоба на то, что, оказывается, теперь надо писать стороннее приложение, неуместна.
Обратите внимание на тему и суть статьи, пожалуйста.
Она о том, чтобы иметь возможность подключаться из терминала к сторонним системам без применения DLL. Задача выполнена - теперь есть легкий способ подключения и полнодуплексного обмена данными.
Жалоба на то, что, оказывается, теперь надо писать стороннее приложение, неуместна.
Обратите внимание на тему и суть статьи, пожалуйста.
Она о том, чтобы иметь возможность подключаться из терминала к сторонним системам без применения DLL. Задача выполнена - теперь есть легкий способ подключения и полнодуплексного обмена данными.
Жалоба на то, что, оказывается, теперь надо писать стороннее приложение, неуместна.
По сути верно, т.к. не декларируется, что штатными методами, т.е. без сторонних костылей, будет обеспечена связь, например, между приложениями на MQL.
"Перед многими разработчиками встает одинаковая проблема - как пробиться в песочницу торгового терминала без применения небезопасных DLL."
Здесь претензий нет и быть не должно.
Но с другой стороны, наиболее востребованная в прикладном плане задача обеспечения связи между приложениями, написанными на MQL, весьма эффективно решается с помощью применения небезопасных dll на примерах из этой статьи. Т.к. в той статье для реализации обеспечения связи через строчные сообщения, достаточно иметь лишь знания и опыт программирования на MQL5 (всю остальную работу, т.е. сторонние костыли через Windows API, автор статьи уже выполнил и выложил в виде готового класса).
А вот связь с внешними системами более важна и применима. Именно для этого и открывался безопасный канал.
Причем обратите внимание, что вся реализация в рамках штатных файловых операций. Никаких новых функций вводить не пришлось.
Напишите свой шлюз на MQL5, отталкиваясь от примеров из вышеупомянутой статьи.
Теоретически можно, но практически получится костыль, да еще и симплексный.
Я тут инфу нашел, как сделать шлюзы с минимальными затратами. Оказывается в С++ есть класс потоков NamedPipeServerStream(String)
Если его вызвать, то он создаст именованный канал. Потом можно дождаться коннекта через вызов метода: IsConnected и создать второй именованный канал. Дожидаемся подключения еще одного клиента ко второму каналу и перенаправляем информацию из первого потока во второй методом: CopyToAsync(Stream). После этого нужно запустить подпроцесс и опять же с помощью CopyToAsync(Stream), перенаправить информацию из второго потока в первый. Так оба именованных канала будут связаны по дуплексу.
Выглядит все это запросто, но я с С++ никакого опыта не имею. Если бы на Java, то работы на полчаса с отладкой.
Пока нашел подходящий пример для переделки: http://msdn.microsoft.com/en-us/library/bb546085.aspx. Попробую на его базе сваять полнодуплексный шлюз на досуге. Вдруг получится?