Ошибки, баги, вопросы - страница 2450
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
О, спасибо, я даже я не в курсе был о таком. Правда у вас там именно и сказано о спотыканиях об макросы. Впрочем будем проверять конечно.
Вы продолжаете развивать этот проект? Так то потенциал действительно огромный, особенно в плане доработки языка своими силами, ибо многое в MQL так и не реализовано, а многое работает через пень-колоду (баги), и разработчики, как я понял, больше не планируют ничего улучшать в самом языке.
Для обработки макросов надо реализовать доп. слой где-то ближе к началу всей цепочки - описать грамматику макросов, распарсить их в исходниках и интерпретировать (получить результат исходник/значение по каждому макросу). Это сложно, а применение требуется только для некоторых MQL-программистов, поэтому развития нет.
Что касается использования хэша для идентификации изменений в продуктах, то мне кажется это не выход (или я не представляю, о каком use-case идет речь). Обычно требуется спустя год-два после генерации какого-то ex-файла понять, какой версии был конкретный встроенный в него модуль и его исходник. Для этого, видимо, нужно процесс сборки стыковать с системами контроля версий. Хэшами не обойтись.
Подскажите, по OnTradeTransaction(). Нижеописанное - нормальное поведение? В тестере проверил - так и есть :( А на "живом" счёте?
В OnTick() есть цикл, закрывающий позиции по порядку.
В OnTradeTrancaction() подсчёт количества открытых позиций.
Советник поступает так: сначала до конца выполняет цикл закрытия, потом переходит к OnTradeTransaction и в том же порядке выполняет подсчёты.
Другими словами не
а
т.е. работает не параллельно, а последовательно.
Если вышеописанное нормально, то получается, что безопасно OnTradeTransaction() можно использовать только в советниках, открывающих/закрывающих только один ордер. Если сетка или мультисимвольный (или мультисимвольнаяя сетка, где это и обнаружилось :) ) - алгоритм ломается.
Цитата из документации
Один торговый запрос, отправленный из терминала вручную или через торговые функции OrderSend()/OrderSendAsync(), может порождать на торговом сервере несколько последовательных торговых транзакций. При этом очередность поступления этих транзакций в терминал не гарантирована, поэтому нельзя свой торговый алгоритм строить на ожидании поступления одних торговых транзакций после прихода других.
Следовательно всё будет посчитано, но не в той последовательности в какой ожидается.
А можете объяснить почему вы решили в OnTradeTrancaction() подсчитывать количество позиций? Если не правильно организовать подсчёт, то не исключён вариант, что будут лишние операции. Ведь если закрыть в цикле несколько позиций нет необходимости пересчитывать все позиции после закрытия каждого. Достаточно посчитать один раз после завершения цикла. Или в в OnTradeTrancaction() организовать так, чтобы при типе IN количество увеличивалось на 1, а при типе OUT уменьшалось. И даже в этом случае, если закрыть позицию не полностью, то это нужно учитывать.
А можете объяснить почему вы решили в OnTradeTrancaction() подсчитывать количество позиций?
Если считать на каждом тике - это ресурсоёмко, особенно заметно в тестере стратегий. Не правильнее ли пересчёт делать только при событии Trade, т.е. когда реально меняется что-то в перечне открытых позиций? С OnTradeTransaction() упрощается контроль за вмешательством пользователя в работу советника. (есть прецеденты :)
В данном роботе тестил возможность закрытия сеток по схеме: убыточная + прибыльная > Х , то закрыть обе (как правило, на разных символах). Но сбой получается, т.к. не смотря на то, что они закрыты, тестер не знает об этом, и переходит к следующей итерации, ошибочно "спаривая" существующие с уже закрытыми. Т.е. пришлось добавить пересчёт после каждого закрытия.
Пересчёт у меня со сбросом счётчика и сначала по всем отрытым, не +1 / -1
Цитата из документации
Согласен, рисковано было изначально использовать OnTradeTransaction() Вообще, наверное, откажусь от неё в случаях когда запросы не асинхронные - одни проблемы от неё.
Для мультисимвольной сетки хороша асинхронность. Поэтому выбрал бы второй вариант.
Уже думаю в этом направлении ;)
***
В данном роботе тестил возможность закрытия сеток по схеме: убыточная + прибыльная > Х , то закрыть обе (как правило, на разных символах).
***
Если знаете, что нужно закрыть именно эти две позиции, то лучше запомнить тикеты этих позиций и закрывать их пока не закроете (ВНИМАНИЕ: никаких while и Sleep - выдали приказы на закрытие, вышли из OnTick, проверили - есть ещё позиции с этими тикетами - если есть, то снова пытаемся закрыть и вышли из OnTick.)
Если знаете, что нужно закрыть именно эти две позиции, то лучше запомнить тикеты этих позиций и закрывать их пока не закроете (ВНИМАНИЕ: никаких while и Sleep - выдали приказы на закрытие, вышли из OnTick, проверили - есть ещё позиции с этими тикетами - если есть, то снова пытаемся закрыть и вышли из OnTick.)
Ценная идея. Может так?: OnTick() формирует массив с тикетами и пытается закрыть один раз, а OnTimer() проверяет есть ли они ещё и закрывает, если есть.
Между тиками может быть несколько минут, поэтому передадим задачу таймеруЦенная идея. Может так?: OnTick() формирует массив с тикетами и пытается закрыть один раз, а OnTimer() проверяет есть ли они ещё и закрывает, если есть.
Между тиками может быть несколько минут, поэтому передадим задачу таймеруЯ бы отказался от ВСЕХ while, Sleep and OnTimer для задачи закрытия позиций. Я бы делал так: выстрелил приказы на закрытие - вышел из OnTick, на следуующем тике проверка: если позиции с нужными тикетами ещё живы - снова выстрелить приказы на закрытие и так по кругу через взход/выход в onTick.
Логика такая: закрытие позиции - первоочередая задача, поэтому цикл закрытия в самом начале OnTick. А формирование массива тикетов закрытия может быть в любом месте OnTick - хоть в самом конце.
***
Между тиками может быть несколько минут, поэтому передадим задачу таймеруЗначит ничего не поделать - только ждать нового тика.
OnTick() формирует массив с тикетами и пытается закрыть один раз, а OnTimer() проверяет есть ли они ещё и закрывает, если есть.
Еще вариант (для реала - самое то), запуск советника в виртуальном окружении (там идеальное исполнение), а в реале только синхронизация с виртуальным.
Значит ничего не поделать - только ждать нового тика.
Если, например, произошел сбой в сети, то ждать следующего тика - упускать возможность закрытия.
Если, например, произошел сбой в сети, то ждать следующего тика - упускать возможность закрытия.
Сбой сети == разрыв соединения имеется в виду? Ну так нет интернета, значит вообще ничего не закрыть ни открыть - какая же здесь упущенная возможность?
И вообще, если торговая система будет очень чувствительна к каждому чиху (разрыв там или ещё что) - то в топку такую торговую систему.