Надо истрию в массив собирать, сортировать как надо, потом уже определять лот. В тестере может быть даже не получится найти момент неправильной работы.
то есть может быть такое, что время закрытия OrderSelect(0, SELECT_BY_POS, MODE_HISTORY) больше чем у OrderSelect(1, SELECT_BY_POS, MODE_HISTORY) ?
в функции //+--------------------------- getLots ----------------------------------+ есть строки: OrderSelect(i, SELECT_BY_POS, MODE_HISTORY); if (OrderSymbol() == Symbol() &&OrderMagicNumber() == mn) { if (OrderProfit() > 0) { result = lots; losses = 0;..... Если профит по выбранному из истории ордеру больше 0, то - возврат к лоту указанному во внешних данных. Ничего удивительного, что после нескольких лосей лот сбрасывается на начальный.
если мое предположение выше неправильно, то код работает как должен. Основня идея: если последний ордер закрылся по профиту то сбрасываем лот, если по sl, то высчитываем его в зависимости от того сколько стопов подряд было
то есть может быть такое, что время закрытия OrderSelect(0, SELECT_BY_POS, MODE_HISTORY) больше чем у OrderSelect(1, SELECT_BY_POS, MODE_HISTORY) ?
если мое предположение выше неправильно, то код работает как должен. Основня идея: если последний ордер закрылся по профиту то сбрасываем лот, если по sl, то высчитываем его в зависимости от того сколько стопов подряд было
в коде указано не OrderSelect( 0, SELECT_BY_POS, MODE_HISTORY), а OrderSelect( i , SELECT_BY_POS, MODE_HISTORY)
В функции OrderSelect(i, SELECT_BY_POS, MODE_HISTORY) идет перебор всех ордеров записанных в истории. Если там записан хоть один ордер советника с данным магиком с профитом то возможно и такое.
Основня идея: если последний ордер закрылся по профиту то сбрасываем лот, если по sl, то высчитываем его в зависимости от того сколько стопов подряд было
А не важно. функция расчета лота возвращает последнее значение лота. и если происходит лось то новый лот должен посчитаться от последнего значения.
в коде указано не OrderSelect( 0, SELECT_BY_POS, MODE_HISTORY), а OrderSelect( i , SELECT_BY_POS, MODE_HISTORY)
Кажется, Вы меня не поняли =)
Я интересовался может ли только что закрытый ордер помещаться не в конец списка в истории? Вот и все. Возможно ли такое? Замечал, что KimIV проверяет OrderCloseTime(). Значит наверное возможно, тогда Integer прав =)
В функции OrderSelect(i, SELECT_BY_POS, MODE_HISTORY) идет перебор всех ордеров записанных в истории. Если там записан хоть один ордер советника с данным магиком с профитом то возможно и такое.
Какое такое?
![MQL5 - Язык торговых стратегий для клиентского терминала MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Есть советник "Universum_4" (исходник прикреплен). Ссылка на описание советника в исходниках.
И есть жалобы, типа:
- у меня советник стоит на 5 парах и постоянно наблюдаются проблемы с лотами. После лося, или оставляет лот как был до этого или сбрасывает на первоначальное значение. И было что вместо 0,06 сделка открылось лотом 5.12 ...
- У меня такая проблема, после 3-4 подряд убыточных ордеров, лот следующего ордера сбрасывается до первоначального, что сводит на нет все предыдущие достижения ...
Тех. задание:
1. Выявить на тестах моменты, где советник после лося сбрасывает лот на первоначальное значение. Предоставить отчет тестера - бектесты с этими самыми моментами.
2. Исправить ошибку в исходниках. Описать в словах в чем заключалась суть бага. Предоставить исправленные исходники.
3. Предоставить отчет тестера - бектест, в котором исправленный советник уже не сбрасывает лот на первоначальное значение.
Первый, кто выполнит вышеприведенное ТЗ, получит 100 WMZ. Выкладываете в этой ветке результаты, а в личку сообщаете номер своего Z кошелька.
Я сколько пытался, но данный баг обнаружить не удалось ни в тестере, ни на счетах.