Ускорение работы эксперта путем запуска дополнительного скрипта - страница 2

 
Yedelkin:
Извиняюсь, что отвлекаю на попутную тему, но по каким причинам пользовательские события могут не дойти до получателя? - Кроме как про переполнение очереди событий больше ничего придумать не могу :/

В том числе и это (верней это один из самых возможных вариантов).

Верней так, события могут и дойти (хотя не факт), но с определенным опозданием.

Да и реализация на мой взгляд не совсем хороша, хотя в настоящих условиях почти одна из лучших. Связано с тем что либо "торгующему" эксперту придется разгребать весь поток сообщений, либо как минимум на каждый символ вешать такого эксперта.

Короче я пока нормально себе этого не представляю, в отличии от реализации при которой индикаторы производят часть анализа и дают приказ эксперту который расположен на их графике.

 

Прошло более года - решения так и нет.

  Interesting 2011.06.17 14:04 

...нужно реализовать вызов скрипта средствами самого MQL5 (подобно тому как происходит работа с индикаторами) и передать в параметрах все нужные  настройки скрипта...

 

Разработчики, есть ли какие-то подвижки в этом направлении? 

 
Rich:

Прошло более года - решения так и нет.

  Interesting 2011.06.17 14:04 

 

Разработчики, есть ли какие-то подвижки в этом направлении? 


Вызов скрипта не реализован да и в принципе не нужен, поскольку код скрипта можно реализовать в виде библы и вызывать когда нужно.

опять же можно написать код скрипта как индикатор и вызывать стандартным способом.

проблема же поднятая топикстартером решена введением нового функционала контроля исполнения торговых приказов OnTradeTransaction.

 
Urain:

Вызов скрипта не реализован да и в принципе не нужен, поскольку код скрипта можно реализовать в виде библы и вызывать когда нужно.

опять же можно написать код скрипта как индикатор и вызывать стандартным способом.

проблема же поднятая топикстартером решена введением нового функционала контроля исполнения торговых приказов OnTradeTransaction.

Он в принципе не нужен Вам. Не обобщайте.

С "костылями" можно по разному, в том числе и по Вашему. Но код скрипта привык писать, как скрипт, а код индикатора - как индикатора.

У меня написаны готовые скрипты, которые формируют файлы нужных мне данных. И необходимо в OnInit() просто проверить наличие этих файлов и если нет - вызвать УЖЕ ГОТОВЫЙ СКРИПТ для их формирования, а не переписывать скрипт, как индикатор и т.д...

 
Rich:

Он в принципе не нужен Вам. Не обобщайте.

С "костылями" можно по разному, в том числе и по Вашему. Но код скрипта привык писать, как скрипт, а код индикатора - как индикатора.

У меня написаны готовые скрипты, которые формируют файлы нужных мне данных. И необходимо в OnInit() просто проверить наличие этих файлов и если нет - вызвать УЖЕ ГОТОВЫЙ СКРИПТ для их формирования, а не переписывать скрипт, как индикатор и т.д...

Создаёте инклюдник, переписываете название функции OnStart в NameScriptOnStart, подключаете в нужный експерт, всё.
 
Urain:
Создаёте инклюдник, переписываете название функции OnStart в NameScriptOnStart, подключаете в нужный експерт, всё.

Это не эквивалентное решение.  Такая функция будет работать в потоке вызвавшего эксперта, а не в собственном. 

Нужны штатные средства для облегчения многопоточных вычислений.  Чем больше тем лучше.  //  У меня вот шесть ядер, а загрузить равномерно - гемор неописуемый. А что будет при 16 ядрах? :(

Как-то дыряво в языке. 

У индикаторов нет простых средств для самозавершения.  Запуск одной программы из другой - через странные костыли в виде шаблонов и бог знает чего ещё.

Нет средств быстрой передачи существенных объёмов информации из потока в поток.  // без использования ДЛЛ даже пайп-сервер не сделаешь.

Доделывать надо всё это.

Юзер не должен ездить в соседний район через Колыму и Париж.  При всём уважении к этим населённым пунктам.

Причина обращения: