Чем в mql4 заменить OnTradeTransaction()? - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
если нужно быстрое решение, то я бы в CArrayInt собрал все тикеты и потом по приходу нового тика сравнивал бы тикеты открытых ордеров с CArrayInt - там метод Search() есть, если нет тикета прекращаем сравнение CArrayInt с тикетами открытых ордеров, сбрасываем CArrayInt и записываем опять все тикеты в CArrayInt и выставляем глобально описанный флаг MyOnTradeTransaction - признак, что изменился список ордеров - код довольно компактный будет
А когда потребуется отловить что-то больше чем пропажа ордера.., тут и начнутся танцы с бубнами...
Проверка OrdersTotal() не покажет активизацию отложенного ордера например - количество ордеров неизменно, тикеты тоже... А когда нужно будет отловить факт модификации ордера/позиции...
Всё впрочем уже придумано, сделано и выложено в свободный доступ с разжовыванием...
Это какие плюсы я отрицаю? У меня только одно отрицание. Я хочу понимать как что работает, а если понять можно только не моим умом, то пользоваться этим мне не комфортно, а всё что мне не комфортно я отрицаю. Я тебе уже говорил, что ты пишешь буковок, больше чем я могу прочесть до конца жизни своей. Не кати на меня бочку...
Плюсы - что не могут потеряться события. В отличие от OnTrade() и OnTradeTransaction(). Но ты не веришь, что такое событие может затеряться... Потому и говорю - дискуссия бессмысленна.
А когда потребуется отловить что-то больше чем пропажа ордера.., тут и начнутся танцы с бубнами...
Проверка OrdersTotal() не покажет активизацию отложенного ордера например - количество ордеров неизменно, тикеты тоже... А когда нужно будет отловить модификацию ордера/позиции...
Всё впрочем уже придумано, сделано и выложено в свободный доступ с разжовыванием...
я и не предлагаю OrdersTotal анализировать, это не надежно
модификацию ордера так не отследишь, нужно тогда свой класс написать на основе CArray или CObj
я предлагал быстрое решение, а не некий фундаментальный труд ;)
Плюсы - что не могут потеряться события.
я и не предлагаю OrdersTotal анализировать, это не надежно
модификацию ордера так не отследишь, нужно тогда свой класс написать на основе CArray или CObj
я предлагал быстрое решение, а не некий фундаментальный труд ;)
могут, если нажать на ПК кнопочку ресет .... давно не слежу за статьями, но помню спрашивал насчет методики сохранения состояния классов в файл на случай перезагрузки терминала - это уже реализовано?А ещё можно с балкона швырнуть комп - для надёжности потери :) А снизу каток пусть ждёт. Потом ещё можно бетоном сверху залить :))
Нет, не реализовано - это сейчас не главное. Это почти на самый конец - проще всё однотипное делать одним махом, а не разбивать на разные временные промежутки. Для меня.
Нет, не реализовано - это сейчас не главное. Это почти на самый конец - проще всё однотипное делать одним махом, а не разбивать на разные временные промежутки. Для меня.
ОК, будем ждать
но у меня получилось наоборот - я уже столкнулся с этой проблемой - не заложил сразу в структуру программы возможность сохранения, начал писать сохранение в файл, очень громоздко все получилось.... потом плюнул и еще раз переписал большую часть кода с нуля - имхо, если предполагается сохранение в файл это нужно сразу реализовывать, хотя бы "заглушками" иначе потом собирать все, что хотел сохранить в каждом классе - очень кропотливая работа, по сути придется весь исходник анализировать
Буду благодарен, если предоставите какой-нибудь воспроизводимый пример (без опроса торговой истории).
Я бы с удовольствием, чтобы отплатить за Ваши полезные дела. У меня, к сожалению, трудно с выковыриванием короткого рабочего кода из очень большого и сложного кода. Который к тому же очень специфичен (напр. открывает только одну позу за раз).
Вот и для Славы пришлось выложить скелет кода вместо компилируемого примера.
Но я постараюсь что-то сделать, а то совесть замучает. Но не быстро.
PS: Я имею в виду, что у меня очень низкая производительность в написании кода. Беру только упорством. И в то же время - сверхзагруженность в доведении советника для скорейшего запуска на реальном счету. Завидую Вашей производительности.
ОК, будем ждать
но у меня получилось наоборот - я уже столкнулся с этой проблемой - не заложил сразу в структуру программы возможность сохранения, начал писать сохранение в файл, очень громоздко все получилось.... потом плюнул и еще раз переписал большую часть кода с нуля - имхо, если предполагается сохранение в файл это нужно сразу реализовывать, хотя бы "заглушками" иначе потом собирать все, что хотел сохранить в каждом классе - очень кропотливая работа, по сути придется весь исходник анализировать
Методы сохранения/загрузки изначально задекларированы. Причём в базовом объекте CObject стандартной библиотеки. А вот в каждый объект библиотеки сразу писать реализацию сохранения в файл - это для одного, ну двух объектов (а значит и статей) ещё можно как-то описать. Но вписывать в каждую статью описания методов сохранения/загрузки - будет довольно скучным чтением практически того же самого "действа" от статьи к статье, а просто упускать - некрасиво по отношению к читателю (и так некоторые говорят, что им тяжело читать такие объёмы статей, вы по-моему - тоже). Поэтому - эта задача для описания в двух-трёх статьях ближе к концу - сразу одним махом, и не сильно нагружая читателя.
Другое дело, если бы ничего не описывалось в статьях - тогда конечно нужно сразу. Тут всё зависит от специфики изложения и целей. Если цель - кодобаза, то всё сразу, а если цель - обучающие статьи - то постепенно - когда время придёт. У меня второй вариант.
Опять упомянули Онтрейд события. Нет проблемы гарантировать OnTradeTransaction для случая потери связи и т.п., ведь терминал всё равно синхронизирует торговое окружение после восстановления связи. Поскольку OnTrade вторичен, значит и полагаться на них можно. Если сами разработчики не допустили косяков, но раз оговорку убрали, значит всё ок.
Но вписывать в каждую статью описания методов сохранения/загрузки - будет довольно скучным чтением практически того же самого "действа" от статьи к статье, а просто упускать - некрасиво по отношению к читателю (и так некоторые говорят, что им тяжело читать такие объёмы статей, вы по-моему - тоже). Поэтому - эта задача для описания в двух-трёх статьях ближе к концу - сразу одним махом, и не сильно нагружая читателя.
я не говорил, что объем статьи для чтения сильно большой, но писал, что объем исходников громадный и невозможно придумать как этим пользоваться без некой справки/FAQ
реализацию сохранения такого большого количества данных буду ждать, интересно посмотреть как это будет выглядеть
реализацию сохранения такого большого количества данных буду ждать, интересно посмотреть как это будет выглядеть
ok