Новая версия платформы MetaTrader 5 build 2940: Перенос витрин MQL5-сервисов в рабочую область и обновление дизайна - страница 26

Новый комментарий
 
Dmitry Fedoseev:

Ордер уже был в истории, но потом был помечен как удаленный и почему-то перемещен со своего места в конец истории, а потом он опять оказался на своем месте. Поэтому лучше бы вообще не перемещать ордер в массиве истории никогда.

Тут что-то с терминологией. Живой ордер не в истории, пока не зальется ПОЛНОСТЬЮ или не будет удален.

Удаление ордера - это не ордер.

Конечно, такой бред никто говорит.

А что вернет тот код - в этом-то и проблема, что в разных случаях он может вернуть разное.

В MQL4 вернет всегда однозначно - всегда последний ордер, что был залит/удален. Это и логично для торговли.

Отсюда вывод - историей отложенных ордеров вообще не следует пользоваться.

Как это не пользоваться?! А анализ качества исполнения? Реджекты, частичные исполнения, проскальзывания. Это все на основе анализа истории не только маркет-ордеров, но и отложенных.

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

Очень частый сценарий:

  1. Стоит BuyLimit на 1 лот.
  2. Он исполняется частично на 0.2 лота - появляется поза. Остается висеть 0.8 BuyLimit.
  3. Поза 0.2 лота закрывается по тейку.
  4. BuyLimit снова исполняется частично на 0.4 лота. Остается висеть 0.4 лота BuyLimit.
  5. Поза на 0.4 лота закрывается по тейку.
  6. BuyLimit на 0.4 лота удаляет советник, как уже неактуальный для рыночной ситуации.

Так вот удаление из п.6. вызывает в новых билдах помещение BuyLimit 0.4 лота в середину таблицы истории для советника. Раньше он помещался в конец таблицы истории для советника. И советник видел, что последний удаленный ордер - этот BuyLimit. Теперь же он его не видит. Искать его БЕЗУМНО дорого.


Не понимаю, зачем надо было портить то, что работало? Кто-нибудь просил ломать? Почему это делается в тихую, без предупреждений? Ну работают же боевые советники, как можно столь важные изменения делать на тихую? Почему нет консультаций с практикующими трейдерами?

 
fxsaber:

Тут что-то с терминологией. Живой ордер не в истории, пока не зальется ПОЛНОСТЬЮ или не будет удален.

Конечно, такой бред никто говорит.

В MQL4 вернет всегда однозначно - всегда последний ордер, что был залит/удален. Это и логично для торговли.

Как это не пользоваться?! А анализ качества исполнения? Реджекты, частичные исполнения, проскальзывания. Это все на основе анализа истории не только маркет-ордеров, но и отложенных.

Очень частый сценарий:

  1. Стоит BuyLimit на 1 лот.
  2. Он исполняется частично на 0.2 лота - появляется поза. Остается висеть 0.8 BuyLimit.
  3. Поза 0.2 лота закрывается по тейку.
  4. BuyLimit снова исполняется частично на 0.4 лота. Остается висеть 0.4 лота BuyLimit.
  5. Поза на 0.4 лота закрывается по тейку.
  6. BuyLimit на 0.4 лота удаляет советник, как уже неактуальный для рыночной ситуации.

Так вот удаление из п.6. вызывает в новых билдах помещение BuyLimit 0.4 лота в середину таблицы истории для советника. Раньше он помещался в конец таблицы истории для советника. И советник видел, что последний удаленный ордер - этот BuyLimit. Теперь же он его не видит. Искать его БЕЗУМНО дорого.


Не понимаю, зачем надо было портить то, что работало? Кто-нибудь просил ломать? Почему это делается в тихую, без предупреждений? Ну работают же боевые советники, как можно столь важные изменения делать на тихую? Почему нет консультаций с практикующими трейдерами?

Да. Отложенные же ордера пока в рынке, их нет в истории... торможу...

В МТ4 подобная беда. Если рыночный ордер закрыть - он добавляется в конец истории, а после перезапуска терминала история отсортирована по времени открытия (точнее - вообще по тикету, но в это никто не верит, ну или когда-то было по тикету, потом по времени сделали, а может не сделали, за всем не уследишь).

Никогда не интересовался отложенными ордерами в истории. Вроде же после перезапуска терминала их вообще нет в истории - поэтому и не пользоваться для серьезных вещей типа обеспечения работы по стратегии.

А то что сломалось что-то, сочувствую, такая реальность тут. Уже давно замечено - как только приспособишься к чему-то, оно меняется - это везде во всем.

 
fxsaber:

Уважаемые разработчики, вы ЧТО натворили?! Вот такой результат теперь на b2962.

Зачем сломали то, что работало правильно? Теперь невозможно синхронизировать. Невозможно во время работы советника узнать по истории, какой ордер был закрыт последним.

На скриншоте четко видно, что стоит сортировка ордеров по времени обработки (не установки).

И поэтому порядок следования тикетов здесь ни при чем

 

Как по мне, каждый эксперт, выставляющий отложки, должен вести учёт своих активных ордеров, отслеживать события изменения состояния ордеров и ещё периодически проверять наличие/состояние ордеров и синхронизировать своё видение (это на случай потери каких-либо событий - обрыв связи, перезагрузка эксперта/MT/компьютера, ...).

Что-то типа:

enum MT_ORD_STATE
  {
   ORD_NA,  // Not available
   ORD_SENT,
   ORD_ACTIVE,
   ORD_CHANGE_SENT,
   ORD_DEL_SENT
  };

struct MTOrder
  {
   ulong id;
   ulong Ticket;
   datetime Time;
   datetime TimeNotFound;
   double   Price;
   double   Vol;
   double   VolInit;
   uint     request_id;
   ENUM_ORDER_TYPE   Type;
   ENUM_ORDER_STATE State;
   MT_ORD_STATE MTState;
   int      Reserved;
   bool     Idf; // Identified
  };

MTOrder  Orders[]; // С начала массива - ордера на покупку, по убыванию цены,
                   // С конца - на продажу, по возрастанию
 
Rashid Umarov:

На скриншоте четко видно, что стоит сортировка ордеров по времени обработки (не установки).

И поэтому порядок следования тикетов здесь ни при чем

Это на вкладке терминала.

А в историческом кэше mql-программы  ордер *126 идет перед ордером *129, хотя дата обработки у него позже. в билде 2940 было иначе.


Уточните пожалуйста, какоц теперь в b2962 порядок  сортировки ордеров в историческом кэше (после вызова HistorySelect)?

 
Rashid Umarov:

На скриншоте четко видно, что стоит сортировка ордеров по времени обработки (не установки).

И поэтому порядок следования тикетов здесь ни при чем

Скриншот привел, чтобы показать, в какой хронологической последовательности было попадание ордеров в таблицу истории. Только для хронологии.

Вы согласны, что если ордер был только что удален, то он должен попадать в конец HistorySelect-истории?


Т.е. вот эти языковые конструкции во время работы советника

должны возвращать (после HistorySelect(0, INT_MAX)) последний попавший в таблицу истории ордер. Сейчас такой ордер попадает не в конец списка, а в середину. До недавнего времени (b295x) так и было. Но сломали. Надеюсь, просто поторопились и исправят.


ЗЫ Уточню, что мы говорим не про GUI, а про HistorySelect-таблицу, что доступна только из MQL.

 
fxsaber:


Вы согласны, что если ордер был только что удален, то он должен попадать в конец HistorySelect-истории?


Т.е. вот эти языковые конструкции во время работы советника

должны возвращать (после HistorySelect(0, INT_MAX)) последний попавший в таблицу истории ордер. Сейчас такой ордер попадает не в конец списка, а в середину. До недавнего времени (b295x) так и было. Но сломали. Надеюсь, просто поторопились и исправят.

Мне кажется, рисковано полагаться на такие вещи.

Надёжнее запросить последние n минут истории и в ней найти нужный ордер - там их не должно быть сильно много.

Если вдруг его там нет - запросить m>n минут.

 
fxsaber:

Вы согласны, что если ордер был только что удален, то он должен попадать в конец HistorySelect-истории?

Это зависит от того как устроена система, например если ордер фактически не удаляется из реестра, а только помечается как удаленный, то его первоначальное положение относительно других ордеров не меняется

 
A100:

Это зависит от того как устроена система, например если ордер фактически не удаляется из реестра, а только помечается как удаленный, то его первоначальное положение относительно других ордеров не меняется

Система устроена так, что до b2958 (включительно) все работало правильно. Дальше уже сломали. Так что это просто непродуманное решение разработчиков. Все пахало отлично, пока не выпустили b2962.

 
JRandomTrader:

Надёжнее запросить последние n минут истории и в ней найти нужный ордер - там их не должно быть сильно много.

Написал выше, что все отлично работало. Ваш вариант жутко тормозной. Здесь несколько недель бились над тем, чтобы убрать огромные тормоза HistorySelect. И это удалось для HistorySelect(0, INT_MAX).

Предложенный вами вариант очень дорог. Понимаю, что некоторых устраивает Trade.mqh из СБ. Но все же говорю о гораздо более продвинутой торговле на MT5.

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