Новая версия платформы MetaTrader 5 build 2715: Общие улучшения - страница 25

Новый комментарий
 
Andrey Khatimlianskii:

Билд 2715, сервер XPMT5-PRD

За 5 минут до закрытия торговой сессии советник шлет 4 приказа на закрытие 4 позиций, везде получает Result.retcode = 10009 (Request completed).

В списке ордеров появляется 4 соответствующих ордера:

Закрывающие ордера выставились. Поскольку закрытия не произошло, MT4Orders на всякий случай предупредил об этом, выдав в лог кучу инфы на случай отладки.

После этого все запросы советника получают Result.retcode = 10039 (A close order already exists for a specified position).

Если закрывающий ордер висит, то, конечно, попытка выставить еще один будет вызывать ошибку.

Так продолжается и на пре-маркете на следующий день (08:55).

В 09:04 пользователь вручную удаляет селл-ордера, и советник тут же успешно закрывает позиции.

Все верно. Как только нет закрывающего ордера, так разрешается его выставить.


Почему закрывающие ордера не срабатывали и остались висеть - вопрос к брокеру. В таких ситуациях нужно было полностью сохранить торговое MT5-окружение, чтобы была информация для анализа и возможного обхода бага.

Пока понятно, что если встречается такой баг, то нужно попытаться отменить закрывающий ордер и тогда выставлять новый. Возможно, имеет смысл такое поведение сделать штатным для OrderClose. Но баг такой, что его отладку произвести крайне затруднительно:

нужно по PositionID закрываемой позиции искать маркет-ордер (лимитные ордера тоже могут иметь ненулевой PositionID). И пытаться удалить его. Сам с рынка позиции не закрываю, поэтому не нарывался.

 
Edgar Akhmadeev:

Крутой баг в дебаггере. И это не тавтология.

Код:

В билде 2741 нормальное поведение (в релизе и дебаге):


В билдах 2743, 2744  (только в дебаге):

Попробуйте убрать выделенное в вашем коде

struct t {
        string  s1;
        string  s2;
};



const t s[] = {
        { "",   "1" },
        { "",   "2" }
};



void
OnStart() {
        string b = "";
        for (int i = ArraySize(s) - 1; i >= 0; --i) {
                Print(i);
                if (s[i].s2 != b) {
                        Print(i);
                        continue;
                }
                
                break;
        }
}
И наверное, заменить >= на просто > но не совсем уверен.
 
Vasiliy Pushkaryov:
У Вас тоже из трех имеющихся размеров в свойствах "Terminal" - 9, 10, 12 - отображение одинаковое. Я просто обратил внимание разработчиков, что есть недоработка, меняю размер шрифта, а ничего не меняется.

Это от нас вообще не зависит - рисует исключительно подсистема Windows GDI.

При мелких размерах, да еще на растровых шрифтах работает система совместимости/приемлемости.

 
Renat Fatkhullin:

Это от нас вообще не зависит - рисует исключительно подсистема Windows GDI.

При мелких размерах, да еще на растровых шрифтах работает система совместимости/приемлемости.

Надо подучить эту тему. Спасибо, что ответили.
 
Andrey Khatimlianskii:

После этого все запросы советника получают Result.retcode = 10039 (A close order already exists for a specified position).

Так продолжается и на пре-маркете на следующий день (08:55).

В 09:04 пользователь вручную удаляет селл-ордера, и советник тут же успешно закрывает позиции.

Это хороший пример, чтобы показать Ренату ситуацию, когда забивается лог гигабайтами текста, вплоть до полного заполнения HDD.

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Ошибки, баги, вопросы

fxsaber, 2021.01.12 09:42

Несколько часов был не у компа. В это время возникла нештатная ситуация и робот стал строчит очень много принтов. В итоге забился полностью диск. А это нарушает работу Терминалов, т.к. они не могут скинуть на диск свою историю цен.


Нужно недопустить подобного забивания диска. Один вариант - запрет записи в папку. Т.е. жить без логов на диске всегда. Другой - убивать лог-файлы, когда осталось мало свободного места.

Кто-нибудь решал такую проблему?


Print и Alert запросто могут убить реальную торговлю сразу на многих Терминалах. И нет никакой защиты. TerminalInfoInteger(TERMINAL_DISK_SPACE) помогает только отключить логирование.

 
Alexey Viktorov:

Попробуйте убрать выделенное в вашем коде

И наверное, заменить >= на просто > но не совсем уверен.

Тогда будет обработка индексов 2 (out of range) и 1, но не 0. Как вы видите, в массиве 2 записи с индексами  1 и 0.

В любом случае речь не об ошибке в коде.

 
В отладчике хотелось бы видеть для datetime не только строку типа D'2020.09.27 00:00:00', но и целое число.
 
Edgar Akhmadeev:

Крутой баг в дебаггере. И это не тавтология.

Код:

В билде 2741 нормальное поведение (в релизе и дебаге):


В билдах 2743, 2744  (только в дебаге):

Тоже наткнулся уже, собрался баг-репортить.

У меня вообще смешно:

        bool CreateBlock( const int id )
        {
                Print( "1 id = ", id );  // тут id = 1
                m_text[id].MainPointer( m_window );
                Print( "2 id = ", id );  // тут id = 706
                m_text[id].XSize( 100 ); // тут critical error

CreateBlock вызывается исключительно с передачей константных 0 и 1.

 
fxsaber:

Все верно. Как только нет закрывающего ордера, так разрешается его выставить.

Вот тут МТ4Orders мог бы просто игнорить повторную отправку закрывающих ордеров, наверное.

А после определенного тайм-аута — сам пытаться отменить старый закрывающий ордер (хотя, не факт, что это ему удастся).

 
Edgar Akhmadeev:
В отладчике хотелось бы видеть для datetime не только строку типа D'2020.09.27 00:00:00', но и целое число.

по моему несложно сделать временную переменную целого типа и присвоить datetime, чтобы посмотреть под отладчиком

1...181920212223242526272829303132
Новый комментарий
Причина обращения: