Ошибки, баги, вопросы - страница 989
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Нет, все машины индивидуальны. Даже оси лицензионные, от хрюши до WS. У меня ощущение презумпции виновности... Надо отмазываться... Оправдываться... Логи, то, се...
А ставить колво лок агентов больше, чем ядер проца нужно запретить на законодательном уровне, и все!
...
А ставить колво лок агентов больше, чем ядер проца нужно запретить на законодательном уровне, и все!
Доброго времени суток. У меня вопрос к разработчикам. Идеальный цикл формирования сделки состоит из следующих этапов:
1.Отправка запроса через OrderSend() с последующей проверкой того, что метод вернул true и корректный retcode.
2.Далее необходимо отслеживать прохождение запроса на сервере через OnTradeTransaction(). Этот обработчик очень удобный и дает полный контроль за процессом.
Однако, мы живем в реальном мире и, например, из-за падения коннекта или просто из-за того, что транзакция "потерялась при доставке", транзакции типа TRADE_TRANSACTION_REQUEST мы можем и не дождаться. Таким образом, цикл ожидания станет бесконечным и будет невозможно определить совершилась ли сделка по запросу или нет.
Существует ли какая-либо УСТАВНАЯ процедура обработки таких аварийных ситуаций с однозначным получением логически корректного завершения процесса при любом форс-мажоре? Например, если мы не дождались TRADE_TRANSACTION_REQUEST в течение 20 (или 30, или 40) секунд, то переходим на более медленный, но верный алгоритм, а именно: сравниваем текущий объем по символу с объемом до OrderSend(), ищем в истории ордер и вычисляем его статус, определяем делать ли еще один запрос на открытие или пропустить сигнал. Для метода OrderSendAsync() задача еще более усложняется - надо иметь точный критерий того, что конкретный ордер не сработал и знать когда этот критерий начинать применять. Если я что-то не так понимаю, то прошу меня поправить.
Для метода OrderSendAsync() задача еще более усложняется - надо иметь точный критерий того, что конкретный ордер не сработал и знать когда этот критерий начинать применять. Если я что-то не так понимаю, то прошу меня поправить.
HistorySelectByPosition - по идее должно помочь, id выдается при отправки ордера.
VanHelsing:
на системах 32х тоже Win7 уже начинаются проблемы в операциях с вещественными числами, на XP так вообще отказывается работать при передаче значений в библиотеку "wininet.dll".
1. Возьмите себе за правило, торговые приказы отправлять на текущем тике, а проверять их исполнение на следующем тике. Тогда у Вас не будет бесконечных циклов.
2. При проверке испонения отданных на предыдущем тике распоряжений, не заморачивайтесь всякими OnTrade()/ OnTradeTransaction(). Проверяйте изменение состояния своего счета, т.е. работайте с первоисточником. Ведь любое торговое располряжение имеет своей целью измененить состояние Вашего торгового счета. Так и проверяйте изменение этого состояния.
3. В зависимости от результатов проверки и делайте дальнейшую логику своего робота.
Прежде чем обращаться к таким функциям как OnTrade()/OnTradeTransaction() , определите что для Вас важнее:
а). добиться открытия/закрытия/модификации позиции при данных рыночных условиях;
б). тратить время на выяснения причины неисполнения Вашего торгового распоряжения и искать виноватых.
Все-таки у меня осталось некоторое недопонимание. Если по результатам проверки на следующем тике мы НЕ получили изменения позиции, то что в этом случае делать. Причины отсутствия изменений могут быть совершенно разными. Как вариант:
ордер по запросу сформирован на сервере, но по каким-то причинам отклонен,
сервер перегружен - исполнение с задержкой,
на какое-то время пропал коннект.
Хотелось бы иметь точный критерий, того, что ордер не был исполнен. Привязка ко времени в асинхронной системе мне кажется не очень точной, допускающей неопределенность. Может быть есть смысл выбирать ордер из истории и проверять его статус или, как предложил sion, использовать HistorySelectByPosition. Я исхожу из того, что если разработчики спроектировали эту систему такой, то должны быть и "правильные" методы отработки таких ключевых операций.
Хотелось бы иметь точный критерий, того, что ордер не был исполнен
вам ведь уже пояснили, что
не заморачивайтесь всякими OnTrade()/ OnTradeTransaction().
работайте с первоисточником
Всем привет!
Как сделать так, чтобы при старте скрипта все содержимое вкладки "Experts" затиралось? (Вроде команды cls), а то бывает сложно разбирать где закончился вывод на печать с предыдущего запуска скрипта и с текущего.
Спасибо!!
Всем привет!
Как сделать так, чтобы при старте скрипта все содержимое вкладки "Experts" затиралось? (Вроде команды cls), а то бывает сложно разбирать где закончился вывод на печать с предыдущего запуска скрипта и с текущего.
Спасибо!!
а вы добавьте в деинит скрипта строку
Print("===================== The End ===================")