Замечена такая не приятная проблема, если запущен скрипт и тот вылетает (закрывает платформу), то лог файл за время работы скрипта не сохраняет записи, а это довольно усложняет выявление ошибки в коде. До этого как-то не замечал такую проблему. Такое всегда было (не сохраняет записи) ?
Похоже, в MT4 никак нельзя узнать (без реконнекта) об изменении торгового плеча на счете.
Лет пять назад делал. У клиента уменьшали плечо в определенные часы, причем оно никак не менялось в переменной AccountInfoInteger(ACCOUNT_LEVERAGE). И ему нужно было знать об этом.
Не знаю как по научному, но для себя определил, что есть плечо по счету, которое меняется редко, а есть по символу, которое могут менять и несколько раз на дню. Проверку делал таким образом:
//+------------------------------------------------------------------------------------------------------------------+//| Проверяет изменение плеча и сообщает если это было//+------------------------------------------------------------------------------------------------------------------+void leverageCheck()
{
if(MarketInfo(Symbol(), MODE_MARGINREQUIRED) == 0) return;
// --- получаем текущее плечо из маржинальных требований, стоимости пункта, тек.котировкиdouble leverageSymb = MarketInfo(Symbol(),MODE_TICKVALUE) * Bid / MarketInfo(Symbol(),MODE_MARGINREQUIRED) / Point;
leverageSymb = int(MathRound(leverageSymb));
// --- если плечо по символу стало меньше на 10% плеча по счету отметим этоif(leverageSymb < percVar(AccountInfoInteger(ACCOUNT_LEVERAGE), -10))
{
string txt = TimeToString(TimeCurrent()) + " Leverage is reduced 1:" + (string)leverageSymb;
Print(txt, " but account leverage = " + (string)AccountInfoInteger(ACCOUNT_LEVERAGE));
// --- вывод информации на график
}
}
//+-------------------------------------------------------------------------------------------------------------------+//| Получает переменную, увеличивает или уменьшает его на переданный процент и возвращает новое значение//| Чтобы уменьшить, нужно передать percent с минусом//+-------------------------------------------------------------------------------------------------------------------+double percVar(double var, double percent)
{
return var*(1 + percent/100);
}
Иногда текущее расчетное плечо по символу leverageSymb могло вместо 200 (когда плечо 1:200) выдавать 199, 198. Поэтому от стандартного плеча приходилось отнимать определенный % и сравнивать с этим значением. Решение выше тогда помогало, может пригодиться.
Лет пять назад делал. У клиента уменьшали плечо в определенные часы, причем оно никак не менялось в переменной AccountInfoInteger(ACCOUNT_LEVERAGE). И ему нужно было знать об этом.
Не знаю как по научному, но для себя определил, что есть плечо по счету, которое меняется редко, а есть по символу, которое могут менять и несколько раз на дню. Проверку делал таким образом:
Иногда текущее расчетное плечо по символу leverageSymb могло вместо 200 (когда плечо 1:200) выдавать 199, 198. Поэтому от стандартного плеча приходилось отнимать определенный % и сравнивать с этим значением. Решение выше тогда помогало, может пригодиться.
Да, с отслеживанием маржинальных требований символа нет проблема. ACCOUNT_LEVERAGE - только реконнект.
вообще зависит от сортировки. если принять по дефолту что сортировка по времени или тикету, новые ордера появляются в конце списка, ну и логично все сдвигаются при удалении самых старых.
Получается при удалении ордера из начала списка один из списка может быть учтен дважды. вроде легко обходится - достаточно запоминать тикет из предыдущего прохода и сравнивать (но гарантии все равно не дает)
Как получить пропуск на обратном проходе - не придумал
вообще зависит от сортировки. если принять по дефолту что сортировка по времени или тикету, новые ордера появляются в конце списка, ну и логично все сдвигаются при удалении самых старых.
Получается при удалении ордера из начала списка один из списка может быть учтен дважды. вроде легко обходится - достаточно запоминать тикет из предыдущего прохода и сравнивать (но гарантии все равно не дает)
Как получить пропуск на обратном проходе - не придумал
Спасибо за подробный ответ! Вот и думаю теперь, как перебрать ВСЕ ордера по ОДНОМУ разу.
Похоже, в MT4 никак нельзя узнать (без реконнекта) об изменении торгового плеча на счете.
Похоже, в MT4 никак нельзя узнать (без реконнекта) об изменении торгового плеча на счете.
Лет пять назад делал. У клиента уменьшали плечо в определенные часы, причем оно никак не менялось в переменной AccountInfoInteger(ACCOUNT_LEVERAGE). И ему нужно было знать об этом.
Не знаю как по научному, но для себя определил, что есть плечо по счету, которое меняется редко, а есть по символу, которое могут менять и несколько раз на дню.
Проверку делал таким образом:
Иногда текущее расчетное плечо по символу leverageSymb могло вместо 200 (когда плечо 1:200) выдавать 199, 198. Поэтому от стандартного плеча приходилось отнимать определенный % и сравнивать с этим значением. Решение выше тогда помогало, может пригодиться.
Лет пять назад делал. У клиента уменьшали плечо в определенные часы, причем оно никак не менялось в переменной AccountInfoInteger(ACCOUNT_LEVERAGE). И ему нужно было знать об этом.
Не знаю как по научному, но для себя определил, что есть плечо по счету, которое меняется редко, а есть по символу, которое могут менять и несколько раз на дню.
Проверку делал таким образом:
Иногда текущее расчетное плечо по символу leverageSymb могло вместо 200 (когда плечо 1:200) выдавать 199, 198. Поэтому от стандартного плеча приходилось отнимать определенный % и сравнивать с этим значением. Решение выше тогда помогало, может пригодиться.
Да, с отслеживанием маржинальных требований символа нет проблема. ACCOUNT_LEVERAGE - только реконнект.
Очень распространена практика фильтрации истории торгов путем запоминания нужных ордеров в список тикетов. А затем SELECT_BY_TICKET по этому списку.
Вариант с запоминанием не тикета, а позиции ни разу не видел. Ниже сравнение производительности.
Видно, что вариант с тикетами проигрывает почти в три раза по производительности.
Видно, что вариант с тикетами проигрывает почти в три раза по производительности.
если будет закрыта\открыта позиция, логика с тикетом не поломается, логика с позицией может.
если будет закрыта\открыта позиция, логика с тикетом не поломается, логика с позицией может.
Речь только о MODE_HISTORY-режиме.
Существует ли теоретическая возможность, что данный код пропустит какой-то ордер, что существовал ДО и ПОСЛЕ вызова функции? Или же учтет дважды.
Т.е. что происходит с индексацией, когда во время перебора какой-то ордер удалится или появится?
Или же учтет дважды.
вообще зависит от сортировки. если принять по дефолту что сортировка по времени или тикету, новые ордера появляются в конце списка, ну и логично все сдвигаются при удалении самых старых.
Получается при удалении ордера из начала списка один из списка может быть учтен дважды. вроде легко обходится - достаточно запоминать тикет из предыдущего прохода и сравнивать (но гарантии все равно не дает)
Как получить пропуск на обратном проходе - не придумал
вообще зависит от сортировки. если принять по дефолту что сортировка по времени или тикету, новые ордера появляются в конце списка, ну и логично все сдвигаются при удалении самых старых.
Получается при удалении ордера из начала списка один из списка может быть учтен дважды. вроде легко обходится - достаточно запоминать тикет из предыдущего прохода и сравнивать (но гарантии все равно не дает)
Как получить пропуск на обратном проходе - не придумал
Спасибо за подробный ответ! Вот и думаю теперь, как перебрать ВСЕ ордера по ОДНОМУ разу.