Пожелания для Meta Trader 4/5

Очень наивно.

Мало кто может устоять от мечты вида "вот сейчас визуально накидаю кубиков и готово". Суровая действительность и длительная практика доказывают, что так не получалось, не получается и вряд ли получится. Мы двигаемся ровно в обратном направлении - делая упор на программистов и предоставляя им полный инструментарий для разработки.

Уважаемый Renat.

Нельзя ли в новой версии Meta Trader 4
в тестере стратегий на страничке "Журнал"
через меню, появляющееся по нажатию правой кнопки мыши
наряду с пунктом "Автопрокрутка" добавить пункты
"Отключить вывод сообщений тестера".
"Отключить вывод логов".

Чтобы в логах оставались только результаты работы эксперта и никаких:

2007.09.04 22:49:44 Expert: loaded successfully
2007.09.04 22:55:37 2006.01.02 07:00 Expert: EURUSD,M1: open #1 buy 0.50 EURUSD at 1.1832 sl: 1.1732 tp: 1.1882 ok
2007.09.04 22:55:38 2006.01.03 06:03 Tester: take profit #1 at 1.1882 (1.1883 / 1.1886)

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

Заранее благодарен.

1)Полноценная возможность играть на истории.
2)Возможность при оптимизации смотреть всю форму пространства двух переменных
при фиксированных значениях всех остальных, а не только лишь лучший результат.
3)Возможность проведения автоматического WFA.
4)Возможность тестирования и оптимизации мультивалютных(портфельных) советников.

Странный ответ. "Политический", как, кстати и многие другие ответы. Я вам не про "светлую мечту", а про интерфейс вообще-то. Да и время тратить на споры о том, что, у кого, и как именно "получается", не буду. Вместо этого предложу вам оставить и развивать сложное программирование, и к этому добавить визуальный интуитивно-понятный конструктор для другой части ЦА платформы. Если его сделать функционально идентичным программированию (пусть даже не сразу), а еще лучше, иметь возможность эти два метода комбинировать, то какая разница, как юзер будет формировать стратегию - кодом, "кубиками", или суммарно?

Видимо, на это вы мне скажете, что "Ресурса не хватает всякой ерундой заниматься. Будем усиленно всю жизнь дудеть в одну дуду". Так примерно?

Теория хороша, но мы практики. Попытки "сделать простое решение для трейдеров" уже были (MQL, MQL2). Об этом я уже много раз писал.

Но с конструктором/визардом мы поработаем - постараемся простые базовые скелеты (не полные программы) делать автоматически.

Очень бы хотелось бы наряду с обычным объявлением переменных иметь к этому ещё и создание аналогичных переменных по стринговому имени, выступающему, как параметр, который можно изменять в процессе работы индикатора или эксперта. По аналогии с глобальными переменными! Например, вот так:

CreatIntVariable("Variable_Name");

Ренат, я бы предложил Вам в будущих версиях подумать над прототипом функции iCustom. В ней сейчас нужно явно писать в коде список параметров, и таким способом нельзя вызвать произвольный индикатор по имени, например, заданном пользователем, поскольку число аргументов любого индикатора заранее неизвестно. Это сильно ограничивает применение iCustom. И к тому же в конце списка аргументов iCustom стоят два параметра вызова (int mode, int shift), т.е. параметры индикатора "разрывают" в прототипе параметры самой iCustom.

Могу предложить такой прототип:

double iCustom( string symbol, int timeframe, string name, int mode, int shift, object[] indicatorParams)

Т.е. в начале все обязательные параметры самой iCustom и последним аргументом функции идёт массив аргументов индикатора произвольного нового типа object (реально это int, bool, double, datetime и другие встроенные MQL типы) с переменным количеством в массиве. Это как раз немного приближает к начальной идее данной темы создания визуального конструктора с вызовом в нём комбинаций произвольных индикаторов. Хотя сама идея нереальна - мне лет 5 назад один человек утверждал, что программисты есть вымерающий класс людей, как ненужная прослойка между специалистами и компьютером. С течением времени прогноз сбывается с точностью наоборот - число и сложность IT решений только растёт.

И неплохо бы иметь для индикаторов функции перебора их аргументов: кол-во IndicatorArgsCount(), ArgsItemName[i] вернёт имя параметра и пр.
А главное - это отладчик в MQL 5.

To chv - возможност использования дефолтными параметрами в iCustom существует и сейчас - см. https://docs.mql4.com/ru/indicators/iCustom

В принципе и сейчас MQL4 представляет все, но все таки можно и больше. Вот и мой список:

1.) Возможност об определения только-что закрытыми по StopLoss или TakeProfit ордерами. Такое можно сделать и сейчас, но довольно сложно. Примерное использование:

3 функции -

int OrderJustClosedCount() - возвращает количество закритых по стопам ордеров

int OrderJustClosed(int pos) - номер тикета

void OrderJustClosedClear() - очищает буфер - сразу после этого OrderJustClosedCount вернет 0 - если обработка продлилась слишком долго.

2.) Для некоторых объектов (напр. канал линейной регресии) после начерчения нельзя прочитать некоторых значения (напр. цена в концов канала).

3.) Добавление чуть больше мат. библиотеки - хотя бы MathArcTan2 - конечно, много уже реализованно на MQL4, но все таки - зачем не встроит их?

Ну а про отладчика - я верю, что уже работаете над этим ;-)

Тогда и список сработавших отложенников.

А вообще, надо просто ввести понятие "событие", и все подобные ситуации можно будет обработать.
Например, событие "сработал ордер", "сработал СЛ", или "ордер удалился по времени истечения".

Вы знаете, прототип функции iCustom я уже читал ;). Того, что надо, "дефолтные параметры" сделать не дают. Вот Вам простейшая задачка - эксперт принимает аргументом в строке имя произвольного индикатора, и, например, в текстовом файле список значений его параметров, разделенных через запятую. Нужно в коде эксперта вызвать этот индикатор по имени с заданными значениями аргументов и получать его значения, ну и допустим печатать их в журнал. В описании iCustom, как мы видим, есть фраза:

...   -   Список параметров (при необходимости). Передаваемые параметры должны соответствовать порядку объявления и типу внешних (extern) переменных пользовательского индикатора.

Вот этого сейчас сделать для произвольного индикатора и нельзя - записать то, не зная чего. На этапе компиляции эксперта число аргументов индикатора и их тип неизвестен. Он определяется только в момент run-time выполнения. В языках программирования это называется "позднее связывание" (late binding). В MQL оно сейчас отсутствует.