Создание GUI для MQL в графическом режиме. - страница 12
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Собственно, никак. Между внешней программой и прог-й в МТ нет никакой разницы. Возможности те-же, взаимодействие то-же самое.
Вообще ничего не объяснил. Четко ответь плз - как ты из МТ* получаешь данные из панели на шарпе?
Я делал обратную связь через Memory Mapping с опросом по таймеру. Панель передавала только разные настройки и результаты медленных расчетов
Незнание дает уверенность. А вот знания умножают печали.
Ок, тогда я сделаю панель отдельно, связь через Memory Mapping. Раньше, в конце 2000-х делал через пайпы, но не понравилось.
Хотя, подключал и напрямую, каких-либо ужасов не заметил.
Терминалу COM-интерфейс - вообще будет крутотень. Хотя и стремительно устаревающая.
Только он ну никак не вяжется с реальным временем :-(
COM -интерфейса скорее всего не будет.
Но можно узнать почему она устаревающая?
Да ещё и стремительно.
COM -интерфейса скорее всего не будет.
Но можно узнать почему она устаревающая?
Да ещё и стремительно.
его заменил .net со своими интерфейсами связи
его заменил .net со своими интерфейсами связи
а в COM одни GUIDы чего стоят
В MS до сих пор скупают обратно неиспользованные GUIDы, по доллару за 10 штук. Если у вас завалялись со старых времен - можете нехило подзаработать!
а в COM одни GUIDы чего стоят
В MS до сих пор скупают обратно неиспользованные GUIDы, по доллару за 10 штук. Если у вас завалялись со старых времен - можете нехило подзаработать!
у меня вот завалились :-) дарю - можешь скинуть в MS
066cd265-e2fe-468e-9492-4228e9759e38
8e1040ba-dc3e-4e2a-9208-e3ea8da9ad05
03dcd7cd-4b9b-4ff7-bff0-e0839a0f9d8b
d69f2c8c-de51-4557-8188-4ebb870da7da
a79a8cc6-f785-4268-bc4e-2deda0f1ecd0
f4f59f52-1da8-4f74-a71e-9aec1992674d
85608797-6015-456d-af64-ad7890120372
9289991a-e287-47fb-b595-6d719c1b7dbd
63d3b953-3229-4045-a82a-fc9e7795bb01
c75c4e0f-8320-42df-943c-9aada54b60eb
если что, обращайся - может ещё найду
Коллеги. Я считаю что спор о том, какая среда разработки лучше, какой код быстрее, лишен всякого смысла. Это все дело вкуса и зависит от решаемых задач. Не зависимо от среды разработки у нас все равно имеются проблемы взаимодействия между внешним приложением и инструментом МТ. Рассмотрим простейший пример. Вы реализовали в нативной dll алгоритм сложных математических вычислений. Из инструмента МТ передали в эту библиотеку нужные параметры и запустили расчет, инструмент продолжил свою работу до окончания расчетов. внешнее приложение закончило расчет и тут встает простой вопрос: как известить инструмент на МТ о том, что расчет завершен? передать данные не проблема, проблема именно в извещении. И повторюсь это этот вопрос не зависит от среды разработки!
Я вижу несколько вариантов:
1. Возможность вызова из внешне программы метода OnChartEvent с помощью например PostMessage
2. Добавление к инструментам МТ нового метода, как предложил Ренат: OnExternal, с указанием типа события или вообще передаваемых данных, то есть в этом методе можно возвращать сами данные
3. Реализация в инструментах МТ винсокета. Это подобно второму пункту, только дает возможность инструменту на МТ подключаться к определенному порту для прослушивания данных
Если первый и второй пункт позволят взаимодействовать на уровне одной машины, то третий пункт обеспечит инструментам МТ сетевое взаимодействие.
Вот пример:https://www.mql5.com/ru/articles/2599
Но тут снова вы встречаем проблему: нужно самостоятельно постоянно проверять наличие данных в сокете.
То есть проблема обратного вызова остается во всех случаях и она не решена.
Мониторинг по таймеру - это не решение, а костыль. Да, за неимением других вариантов так сейчас и решаем.
Если разработчики внедрят на уровне платформы решение этих вопросов, тогда никакой доступ к API терминала и не потребуется. Ведь его просят не от хорошей жизни, а потому что нет полноценного взаимодействия между МТ и создаваемыми приложениями. И повторюсь: эта проблема существует не зависимо от выбранной среды разработки внешнего приложения.
Информация о возможности использования net библиотек ))) https://www.mql5.com/ru/forum/13388
Тема в принципе очень стара. Сами же разработчики некогда объявили о возможности работы с net без заморочек.. с тех пор много воды утекло, но вопрос остался не решенным...
Или вот, сообщение от самого Рената: https://www.mql5.com/ru/forum/3153/page2#comment_298866
https://www.mql5.com/ru/forum/3153/page2#comment_298892
Коллеги. Я считаю что спор о том, какая среда разработки лучше, какой код быстрее, лишен всякого смысла. Это все дело вкуса и зависит от решаемых задач. Не зависимо от среды разработки у нас все равно имеются проблемы взаимодействия между внешним приложением и инструментом МТ. Рассмотрим простейший пример. Вы реализовали в нативной dll алгоритм сложных математических вычислений. Из инструмента МТ передали в эту библиотеку нужные параметры и запустили расчет, инструмент продолжил свою работу до окончания расчетов. внешнее приложение закончило расчет и тут встает простой вопрос: как известить инструмент на МТ о том, что расчет завершен? передать данные не проблема, проблема именно в извещении. И повторюсь это этот вопрос не зависит от среды разработки!
Я вижу несколько вариантов:
1. Возможность вызова из внешне программы метода OnChartEvent с помощью например PostMessage
2. Добавление к инструментам МТ нового метода, как предложил Ренат: OnExternal, с указанием типа события или вообще передаваемых данных, то есть в этом методе можно возвращать сами данные
3. Реализация в инструментах МТ винсокета. Это подобно второму пункту, только дает возможность инструменту на МТ подключаться к определенному порту для прослушивания данных
Если первый и второй пункт позволят взаимодействовать на уровне одной машины, то третий пункт обеспечит инструментам МТ сетевое взаимодействие.
Вот пример:https://www.mql5.com/ru/articles/2599
Но тут снова вы встречаем проблему: нужно самостоятельно постоянно проверять наличие данных в сокете.
То есть проблема обратного вызова остается во всех случаях и она не решена.
Мониторинг по таймеру - это не решение, а костыль. Да, за неимением других вариантов так сейчас и решаем.
Если разработчики внедрят на уровне платформы решение этих вопросов, тогда никакой доступ к API терминала и не потребуется. Ведь его просят не от хорошей жизни, а потому что нет полноценного взаимодействия между МТ и создаваемыми приложениями. И повторюсь: эта проблема существует не зависимо от выбранной среды разработки внешнего приложения.
дополню про мониторинг и опросы, просто не все это знают - чтобы не дёргать DLL при каждом опросе, можно завести int[] для "расшаривания" флагов. Внутри DLL весь доступ к ним как __atomic__ .
В принципе это работает и довольно экономно по ресурсам, но приходится полагаться на то что со стороны MQL инкремент/декремент тоже атомарны и оптимизатор не делает предположений о значениях.
int flags[1]={0}; // когда DLL досчитает она инкрементит флаг
handle=InitDLL(flags); //
...
// опрос типично выглядит так:
while ( flags[0] ) // проверить один int это очень быстро
{
flags[0]--;
ReadDataFromDLL(handle);
}
Чтобы совсем захорошело было-бы достаточно аттрибута atomic (volatile?) и набора соотв.примитивов. На мой взгляд это проще чем встраивать в систему новый механизм и не меняет существующий протокол DLL
дополню про мониторинг и опросы, просто не все это знают - чтобы не дёргать DLL при каждом опросе, можно завести int[] для "расшаривания" флагов. Внутри DLL весь доступ к ним как __atomic__ .
В принципе это работает и довольно экономно по ресурсам, но приходится полагаться на то что со стороны MQL инкремент/декремент тоже атомарны и оптимизатор не делает предположений о значениях.
int flags[1]={0}; // когда DLL досчитает она инкрементит флаг
handle=InitDLL(flags); //
...
// опрос типично выглядит так:
while ( flags[0] ) // проверить один int это очень быстро
{
flags[0]--;
ReadDataFromDLL(handle);
}
Чтобы совсем захорошело было-бы достаточно аттрибута atomic (volatile?) и набора соотв.примитивов. На мой взгляд это проще чем встраивать в систему новый механизм и не меняет существующий протокол DLL
Максим, и чем это решение лучше? Ведь для опроса состояния флага так же необходимо делать его периодическую проверку в MQL. Получается куда не копни, нужно постоянно мониторить изменение состояния чего либо, чтобы понять что пора забрать данные. А этот фраг можно и в самой dll хранить и там его проверять, что я и делаю. В твоем примере происходит неявный вызов dll для возвращения состояния флага.