
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Всё, решение простое: вводим ещё одну проверку на изменение истории, таким образом ничего не пропадёт и отработает на 100%
Это даже можно использовать как неполноценный OnTrade()
Видать слаб умом)
Как это применить?
Проблема всего одна и она крайне редкая, сегодня её обнаружил впервые за пару лет, может и перед этим была, просто не замечал
Я говорил о подсчёте хэш-суммы - каким образом можно наименование символа добавить к ulong-значению хэш-суммы - посчитать значения кодов букв, входящих в состав наименования символа.
Всё, решение простое: вводим ещё одну проверку на изменение истории, таким образом ничего не пропадёт и отработает на 100%
Вот выдержка из моей статьи №3:
-------
Остановимся подробнее на хэш-сумме в составе структуры.
Рассмотрим тикет. Добавление/удаление отложенного ордера изменит общую сумму тикетов на счёте, срабатывание отложенного ордера не изменит общую сумму тикетов на счёте.Чтобы мы могли точно определить произошедшее изменение на счёте, нам недостаточно будет знать количество ордеров и позиций — отложенный ордер может быть удалён, и в этом случае изменится общее количество ордеров и позиций на счёте. Но... отложенный ордер может сработать и стать позицией. В этом случае общая сумма ордеров и позиций не изменится (для хэджевых счетов и MQL4) — количество позиций увеличилось, но количество ордеров уменьшилось, и в итоге общее количество осталось прежним. Это нам не подходит.
Рассмотрим общий объём. Выставили или удалили отложенный ордер — общий объём на счёте изменился, открыли, закрыли, или изменили позицию — общий объём на счёте изменился. Вроде подходит, но опять активация отложенного ордера не изменит общего объёма.
Значит смотрим ещё одно свойство позиции — время её изменения в милисекундах: открытие новой позиции изменит общее время изменения позиции, частичное закрытие изменит время изменения позиции, добавление объёма на неттинговом счёте изменит общее время изменения позиции.Что из всего этого нам подойдёт для однозначного определения произошедшего изменения на счёте? Тикет+время изменения позиции. Проверим:
Тут я, правда, символ не добавлял к хэш-сумме - не было на то прецедентов. Но у меня работает совместно с проверкой истории. Посему - должно отрабатывать без ошибок. Впрочем, проверю как-нибудь.
Всё, решение простое: вводим ещё одну проверку на изменение истории, таким образом ничего не пропадёт и отработает на 100%
А вот и да. Если не изменится количество открытых ордеров, то изменится количество в истории. (меня отложки не беспокоят - я их не пользую) И не надо лохматить бабушку перебирать ордера по чём зря весь день для отлавливания одного лишь события.
А если юзеру пришла СМСка в голову и он решил историю в терминале отразить вместо всей только за последний месяц, то просто выполнится лишняя проверка с перебором всех ордеров, что не смертельно ну вот ни разу.
Вроде годное решение. И без привязки к чему-бы то ни было пользуясь только тем, что есть - а есть торговый счёт и терминал.
Вот выдержка из моей статьи №3:
-------
Остановимся подробнее на хэш-сумме в составе структуры.
Рассмотрим тикет. Добавление/удаление отложенного ордера изменит общую сумму тикетов на счёте, срабатывание отложенного ордера не изменит общую сумму тикетов на счёте.Чтобы мы могли точно определить произошедшее изменение на счёте, нам недостаточно будет знать количество ордеров и позиций — отложенный ордер может быть удалён, и в этом случае изменится общее количество ордеров и позиций на счёте. Но... отложенный ордер может сработать и стать позицией. В этом случае общая сумма ордеров и позиций не изменится (для хэджевых счетов и MQL4) — количество позиций увеличилось, но количество ордеров уменьшилось, и в итоге общее количество осталось прежним. Это нам не подходит.
Рассмотрим общий объём. Выставили или удалили отложенный ордер — общий объём на счёте изменился, открыли, закрыли, или изменили позицию — общий объём на счёте изменился. Вроде подходит, но опять активация отложенного ордера не изменит общего объёма.
Значит смотрим ещё одно свойство позиции — время её изменения в милисекундах: открытие новой позиции изменит общее время изменения позиции, частичное закрытие изменит время изменения позиции, добавление объёма на неттинговом счёте изменит общее время изменения позиции.Что из всего этого нам подойдёт для однозначного определения произошедшего изменения на счёте? Тикет+время изменения позиции. Проверим:
Тут я, правда, символ не добавлял к хэш-сумме - не было на то прецедентов. Но у меня работает совместно с проверкой истории. Посему - должно отрабатывать без ошибок. Впрочем, проверю как-нибудь.
Жирное решение, пока нет надобности для такого варианта.
Спасибо!
Жирное решение, пока нет надобности для такого варианта.
Спасибо!
"Жирное" потому, что делалось не для локального решения, а как одна из частей полноценной замены OnTradeXXXX. Там в составе ещё работа с историей.
И как огромный плюс - уже готовые данные для поиска и сортировки в любой надобности любых ордеров и позиций в программе (не нужно заново искать ордера и позиции для потребностей программы - всё уже лежит в списках). И ещё один плюс - программа знает от какого ордера была порождена позиция в MQL4, чего нельзя сделать в вариантах, озвученных выше.
Но, повторюсь - библиотека делается для облегчения жизни тех, кому самому всё это делать очень долго и накладно. Ни на чём не настаиваю, естественно :)
А вот и да. Если не изменится количество открытых ордеров, то изменится количество в истории. (меня отложки не беспокоят - я их не пользую) И не надо лохматить бабушку перебирать ордера по чём зря весь день для отлавливания одного лишь события.
А если юзеру пришла СМСка в голову и он решил историю в терминале отразить вместо всей только за последний месяц, то просто выполнится лишняя проверка с перебором всех ордеров, что не смертельно ну вот ни разу.
Вроде годное решение. И без привязки к чему-бы то ни было пользуясь только тем, что есть - а есть торговый счёт и терминал.
Чтобы не перебирать весь день можно же проверку делать только когда соблюдены условия которые могут привести с изменению,открытию,закрытию позиции, т.е. ориентироваться на достижение тех цен, которые эксперт использует для открытия, ТП, СЛ. Ну да от логики эксперта зависит, вам там виднее что дешевле.
Чтобы не перебирать весь день можно же проверку делать только когда соблюдены условия которые могут привести с изменению,открытию,закрытию позиции, т.е. ориентироваться на достижение тех цен, которые эксперт использует для открытия, ТП, СЛ. Ну да от логики эксперта зависит, вам там виднее что дешевле.
Один советник (на одном компе, на одном континенте) торгует. Другой (на другом компе, на другом континенте) занимается своими функциями. Решение уже найдено.
Буду благодарен, если предоставите какой-нибудь воспроизводимый пример (без опроса торговой истории).
Вот что получилось (хотя здесь оффтопик, но здесь просили).
Резал по живому. Без совместимости с MT4 (естественно), без обработки ошибок и т.д.
Торговля примитивная, открывает BUY, закрывает по SL/TP. Смысл только в демонстрации OnTradeTransaction() vs "опрос сервера".
У меня за указанный промежуток проход занял 2.34s vs 3.06s. Разница небольшая из-за малой нагрузки на серверные функции (только одна позиция, нет проверки магик и символа). В реальном эксперте разница будет много больше. Разница слегка будет нивелироваться за счёт расчёта сигналов и добавления трейлинга, но их необязательно делать на каждом тике. У меня ATR рассчитывается на M1, но за 6 часов (т.е. есть пространство для укрупнения TF). А трейлинг и безубыток рассчитывается на H3. Всё зависит от статегии.
Вы безнадежно отстали от жизни!
Давно эти события гарантированы!
Допустим, произошло событие в OnTradeTransaction() после которого необходимо выполнить какие-то действия, но при первой попытке выполнить эти действия произошла ошибка. Что делать? Очевидно, надо повторить попытку, а для этого нужно где-то сохранить данные о необходимости повторения этих действий - скорее всего сохранение этих данных делается в обычных глобальных переменных советника или в статических функции. И вдруг пришлось перезапустить терминал... данные пропали.
А когда анализируешь текущую ситуацию и историю - ничто никуда не улетает.