MetaTrader 4 Client Terminal build 610 - страница 106

 
Rosh, спасибо. Действительно, но не заметил, видимо название Журналы в MetaTrader Market и новый MetaViewer отвлекло внимание от Главного смысла. Сорри, но я не сторонник маркета. Как то мы с Вами в свое время и без него обходились и общение было, и обмен идеями, кодами и т.д. За платформу спасибо. Успехов и наилучшие пожелания всей команде.
 

Может ктото замечал:

если из сова сделать запрос на индикатор и передать в индикатор тип данных datetime, соответственно у индикатора тоже такой же тип данных, то терминал начинает на каждом тике писать Custom indicator...loaded successfully, если сова удалить с графика то появится такой же список сообщений Custom indicator... removed

если у индикатора заменить тип данных с datetime на int то все как надо

я так понимаю это терминальные проблемы? у индикаторов не должно быть типа данных datetime ?

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


 

Здравствуйте

После обновления терминала появилась проблема, которой раньше не было.

Последовательность действий следующая:

- выполняем оптимизацию

- во вкладке "Результаты оптимизации" выбираем один из результатов. Нажимаем на правую кнопку, выбираем команду "Установить входные параметры".

- запускаем тестер снова, нажимаем на Старт в вкладке настройки

В результате выбранные параметры не будут использованы.

Для того чтобы они использовались нужно дополнительно нажимать на "Свойства эксперта" и OK после оптимизации.

Версия терминала у меня сейчас 610.

 

Снова по теме вопроса Вольдемара, который тут https://www.mql5.com/ru/forum/149655/page94#930272

Список членов выпадает не везде.

Если в инклюднике прописать руками, то все нормально работает. Но список не выпадает.

Что я не так делаю?

Windows 7x64 максимальная. Билд 620. Установлен на диске Е:, папка MQL4 в папке с терминалом.

Файлы:
mql4.zip  2 kb
 

Ещё момент. Подсветка параметров.

А так в инклюде.

 
GSB:

В первой строке ошибка :), последняя осознано, поскольку он выходит по времени открытия ордера, а он в самом худшем случае последний и сам не нужен. Все эти комиссионные записываются после времени открытия ордера которым открыта позиция или уже закрыта, их тикеты выше. Насчет неправильности не согласшусь, поскольку еще раз подчеркну что ищется по конкретному тикету сделки который уже в истории записан в комменте под тикетом выше чем открывали с типом 6 . Если его там нет в комментах и именно с 6 типом и соответствующей записью типа " Roll" "Commission", то возвратит ноль. Как только открыл позицию, так в истории идет запись под тикетом выше открытого и в комменте ссылка на текущую позицию. Закрыл, вторая запись и опять тот же коммент, и тикет естественно более старший.

Началось. :)

Это сегодня ордер в списке - последний, а завтра - какой-нибудь другой. Разве порядок документирован?

Это сегодня комиссионные записываются после времени открытия ордера, и их позиция выше. А завтра?

А если завтра для комиссий станут использоваться ордера с типом 7, а для снятий/пополнений - с типом 6 (между прочим, имеют полное право, ибо типы - недокументированные)?

А если в комментарии начнут писать "Comission (NOT Rollover) - NNNNN" и "Rollover (NOT Comission) - NNNNN", - что насчитает данный алгоритм?

И по коду ещё достаточно "интересных мест".

double f_OrderFee(int tckt, datetime oot)
{
   double ord_com=0, ord_swp=0, fee=0;
   int oht=OrdersHistoryTotal();
   for (int j=oht-1; j>0; j--)
   {
      if(!OrderSelect(j,SELECT_BY_POS,MODE_HISTORY))  continue; // Пусть здесь вызов ни разу успешно не выполнился
      ...
   }
   // while position is open the commission is 1/2 in history
   if(OrderCloseTime()<=0) fee=NormalizeDouble(2*ord_com+ord_swp,2); else fee=NormalizeDouble(ord_com+ord_swp,2);
   //Print("f_OrderFee ",NormalizeDouble(2*ord_com+ord_swp));
   OrderSelect(tckt,SELECT_BY_TICKET); // backUp SELECT position
     
   return(fee);
}

В документации для OrderCloseTime() указано, что "Ордер должен быть предварительно выбран с помощью функции OrderSelect()". Однако, в случае, когда OrderSelect() в теле цикла ни разу успешно не выполнился, то вызов OrderCloseTime() после цикла осуществится без предварительного вызова OrderSelect(), что неправомерно, или, если вызов OrderSelect() был ранее выполнен вне пределов функции f_OrderFee(), то вызов OrderCloseTime() вернёт что-то явно не то, что задумано.

Насколько я понимаю, первый параметр функции f_OrderFee() служит для того, чтобы в конце функции "перевыбрать" order по ticket'у, видимо, того order'а, который был выбран, и этот выбор использовался, до вызова функции f_OrderFee(). Чтобы вызов функции f_OrderFee() не "испортил" тот текущий "выбор", который был до вызова этой функции. Поскольку в теле цикла выбор может "испортиться", в конце функции выполняется соответствующий вызов OrderSelect() для "backUp SELECT position" (на самом деле - restore).

Однако, что будет, если текущий "выбор", который был до вызова функции f_OrderFee(), "испортится" телом цикла, а последующий вызов OrderSelect() для "backUp SELECT position" в конце функции осуществится неуспешно?

Проверки на это нет, и функция f_OrderFee() никак не сигнализирует вызывающему коду, что подобное случилось. И вызывающий код будет работать с order'ом, который последний раз был успешно выбран в теле цикла (для случая, когда хотя бы один order был в теле цикла успешно выбран).

 
simpleton:

Началось. :)

В документации для OrderCloseTime() указано, что "Ордер должен быть предварительно выбран с помощью функции OrderSelect()". Однако, в случае, когда OrderSelect() в теле цикла ни разу успешно не выполнился, то вызов OrderCloseTime() после цикла осуществится без предварительного вызова OrderSelect(), что неправомерно, или, если вызов OrderSelect() был ранее выполнен вне пределов функции f_OrderFee(), то вызов OrderCloseTime() вернёт что-то явно не то, что задумано.

Насколько я понимаю, первый параметр функции f_OrderFee() служит для того, чтобы в конце функции "перевыбрать" order по ticket'у, видимо, того order'а, который был выбран, и этот выбор использовался, до вызова функции f_OrderFee(). Чтобы вызов функции f_OrderFee() не "испортил" тот текущий "выбор", который был до вызова этой функции. Поскольку в теле цикла выбор может "испортиться", в конце функции выполняется соответствующий вызов OrderSelect() для "backUp SELECT position" (на самом деле - restore).

Однако, что будет, если текущий "выбор", который был до вызова функции f_OrderFee(), "испортится" телом цикла, а последующий вызов OrderSelect() для "backUp SELECT position" в конце функции осуществится неуспешно?

Проверки на это нет, и функция f_OrderFee() никак не сигнализирует вызывающему коду, что подобное случилось. И вызывающий код будет работать с order'ом, который последний раз был успешно выбран в теле цикла (для случая, когда хотя бы один order был в теле цикла успешно выбран).


1. Замечания в части абзаца после кода приняты, спасибо, хотя тон мягко говоря оставляет желать лучшего.

2. Изначально вопрос был задан так - что за ордер типа 6. Я прокомментировал и привел пример кода исключительно для объяснения а не для практического использования что неоднократно подчеркивал. Я вообще не встречал здесь кого либо работающего с FXCM у которого мост для МТ собственной разработки и такая форма учета и записи комиссионных и свопов, и только при институционном спрэде при депо от 50к. Вопрос совершенно не актуален с позиций реального использования, поэтому предлагаю прекратить обсуждение. Если у кого то есть аналоги подобного рода записей с другими брокерами, то можно продолжить обсуждение в отдельной ветке.

 

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

 
simpleton:

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

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

Разработчикам.

Функция SymbolInfoInteger(Symbol(),SYMBOL_TRADE_MODE) при тестировании дает 0 SYMBOL_TRADE_MODE_DISABLED. Это неверно. Зачем при тестировании ограничения по торгам по инструменту?

Скрипт на закрытом рынке дает 2 SYMBOL_TRADE_MODE_FULL

Причина обращения: