Ошибки, баги, вопросы - страница 3720

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

Заголовок: Баг MetaEditor 5 (Build 5660): Ошибка обновления #property indicator_buffers в проектах (.mqproj)


Приветствую!


Обнаружил критический баг при разработке индикаторов в режиме проекта (.mqproj), который периодически блокирует работу.


Суть проблемы:

При попытке увеличить количество буферов через директиву #property indicator_buffers (например, с 5 до 8), компилятор выдает предупреждение:

"property already exists with different value and will be skipped"


Это происходит рандомно: иногда изменение проходит успешно, но в какой-то момент проект "заклинивает" на старом значении. В результате терминал выделяет память под старое кол-во буферов, что приводит к ошибке "array out of range" при обращении к новым индексам в коде.


Технические данные:

- Терминал: MetaTrader 5 Build 5660.

- ОС: Windows 10.

- Тип файла: Проект (.mqproj) в папке Shared Projects.


Ключевые наблюдения:

1. Ошибка привязана именно к файлу проекта. Если сделать копию основного .mq5 файла в той же папке и скомпилировать её отдельно — ошибка пропадает, и всё работает корректно.

2. Возвращение к старому значению (которое "запомнил" проект) убирает предупреждение.

3. Ошибка проявляется не сразу, а в процессе активной разработки, когда количество буферов меняется несколько раз.

4. Пересоздание проекта помогает, но это плохой вариант (костыль), так как теряется история коммитов в MQL5 Storage и возникают конфликты имен при пуше в гит.


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


Скриншоты прилагаю:

1) Предупреждение в логах.

2) Исчезновение ошибки при откате значения.

3) Успешная компиляция копии того же кода вне структуры проекта.

Файлы:
1.png  75 kb
2.png  67 kb
3.png  92 kb
 
fxsaber #:

Это минимальный спред (такое вынужденное официальное заглядывание в будущее) за время жизни всего бара, а не спред на открытии.

Сравните Open[0].ask в разных режимах Тестера.

А что это меняет? Минимальный он или ещё какой, нам то какая разница? 

Есть спред, нет спреда, не важно.

Был гэп, было закрытие позиции по стоп лоссу.

Если мы запишем закрытие позиции по цене открытия свечи или по цене стоп лосса , в каком случае буде меньше погрешность с реальным закрытием (закрытием на более точных режимах тестирования) ?

 
fxsaber #:
В общем, мало данных. Поэтому отсутствует проскальзывание у отложенных ордеров и SL/TP.

В моем конкретном примере все данные одинаковые на момент срабатывания SL как в OHLC, так и в Every tick. SL срабатывает на открытии новой свечи и за счет гэпа.При этом режимы "Every tick" берут Bid для DEAL_PRICE_OUT, а OHLC - сам SL. Хотя на первом "даже смоделированном" тике свечи в OHLC режиме у тестера есть ровно те же Ask/Bid, что и в Every tick режимах (скрины).

Получается, в конкретно этом примере причина не в недостатке данных, а именно в разной логике выбора DEAL_PRICE_OUT.


Aleksandr верно подметил, что проскальзывания внутри свечей КОНЕЧНО могут сильно отличаться в разных режимах как раз из-за недостатка данных и их эммуляции в OHLC, но почему на гэпах логика такая разная не понгятно. Если была бы одинаковая, в таких ситуациях можно было бы сильно сблизить OHCL с Every tick.

Aleksandr Slavskii #:

Насчёт отсутствия проскальзывания внутри свечей согласен, его быть не может, а вот проскальзывания при открытии свечи с гэпом вполне возможно сделать и в режиме тестирования OHLC.

Это значительно приблизило бы тестирование по OHLC к более точным режимам тестирования.

 
Aleksandr Slavskii #:

А что это меняет? Минимальный он или ещё какой, нам то какая разница? 

Есть спред, нет спреда, не важно.

Был гэп, было закрытие позиции по стоп лоссу.

Если мы запишем закрытие позиции по цене открытия свечи или по цене стоп лосса , в каком случае буде меньше погрешность с реальным закрытием (закрытием на более точных режимах тестирования) ?

Абсолютно поддерживаю.

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

зачем разную логику реализовали?

 
Aleksandr Slavskii #:

Был гэп, было закрытие позиции по стоп лоссу.

Открыта SELL-позиция. Был гэп по Bid-цене. Какое это имеет отношение к Ask-цене, по которой нужно закрывать позицию?

 
fxsaber #:

Открыта SELL-позиция. Был гэп по Bid-цене. Какое это имеет отношение к Ask-цене, по которой нужно закрывать позицию?

 spread мы знаем? Знаем.

Bid + spread == Ask 

Ask < SL  ?  закрываем позицию по SL 

Что лучше записать в отчёт, цену  Ask или цену SL ?

 
Aleksandr Slavskii #:

 spread мы знаем?

Нет.

 
fxsaber #:

Нет.

Ну это мы на второй круг пошли, так не годится.

Лучше совсем остановиться чем повторяться.

Зачем мне разные режимы сравнивать? Меня интересует OHLC.

есть бид, есть аск и всё это на открытии свечи в тестере.

что ещё надо?

 
Aleksandr Slavskii #:

Ну это мы на второй круг пошли, так не годится.

Для DEAL_BUY и DEAL_SELL должны быть одинаковые правила акцепта. Если можете написать такое правило в коде - сделайте. Проще код обсуждать, а не трактовки слов.

Вот для тикового режима. 
void CheckSL()
{
  const double SL = PositionGetDouble(POSITION_SL);
  MqlTick Tick;
  
  if (SL && SymbolInfoTick(PositionGetString(POSITION_SYMBOL), Tick))
  {
    if (PositionGetInteger(POSITION_TYPE)) // SELL
    {
      if (SL >= Tick.ask)
        PositionClose(); 
    }
    else if (SL <= Tick.bid)
      PositionClose(); 
  }
}


Для OHLC-режима данные цен только такие.

void CheckSL()
{
  const MqlRates Bar1; // Закрывшийся бар.
  const MqlRates Bar0; // Открывшийся бар (open = high = low = close).

// ....
}
 
Aleksandr Slavskii #:

есть бид, есть аск и всё это на открытии свечи в тестере.

Мнимый аск. Тестер не может допускать перекосы для позиций разных направлений. Правила едины. На открытии в OHCL-режиме известна только Bid-цена. Эмуляция Ask не идет в расчет.
1...371337143715371637173718371937203721372237233724372537263727...3768
Новый комментарий