Ошибки, баги, вопросы - страница 3515
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Простите, но я не вижу причин, почему сервер, который отправляет данные на OTT, не отправляет полные данные!!!
Транзакция в таблицы live/history orders/deals/positions приходят не одновременно с приходом в советник. Более того, OnTradeTransaction внутри Терминала (скрытый, не советника) может иметь задержки обработки пришедшей информации. А советник, получивший то же сообщение, отработать без задержек. Верно и в обратную сторону.
Поэтому невозможно гарантировать, что OnTradeTransaction придет в советник сразу после того, как эта транзакция закончила обрабатываться в Терминале.
Транзакция в таблицы live/history orders/deals/positions приходят не одновременно с приходом в советник. Более того, OnTradeTransaction внутри Терминала (скрытый, не советника) может иметь задержки обработки пришедшей информации. А советник, получивший то же сообщение, отработать без задержек. Верно и в обратную сторону.
Поэтому невозможно гарантировать, что OnTradeTransaction придет в советник сразу после того, как эта транзакция закончила обрабатываться в Терминале.
And if everything gets random and mixed up because of this, what sense does OnTradeTransaction (OTT) make?
I know this is a thread race problem, but parallel processing does not explain the missing information: Request{} = Result{} = {Zero} ??
How is the EA supposed to find its order now? The MagicNumber is missing in MqlTradeTransaction. Symbol is missing in MqlTradeResult. ...
Very often two of the three structures OTT's are not filled in (=all zero).
TRhe MQ-rule of 1 second? For many EAs? When does the EA know that everything has arrived to go on if OTT is called again and again due to the other EAs?
Tell me a valid, programmable rule! I don't see one, and that in a financial software for professional use. It's a runaway.
Would it be so difficult(?) to at least(!) always(!) send MqlTradeRequest as the EA has filled it out(!)?
И если из-за этого все перемешивается, то какой смысл имеет OnTradeTransaction (OTT)?
Я знаю, что это проблема гонки потоков, но параллельная обработка не объясняет отсутствие информации: Request{} = Result{} = {Zero} ?
Как советник теперь должен найти свой ордер? MagicNumber отсутствует в MqlTradeTransaction. Символ отсутствует в MqlTradeResult. ...
Очень часто две из трех структур OTT не заполнены (=все нули).
TRhe MQ-правило 1 секунды? Для многих советников? Когда советник понимает, что все готово к продолжению работы, если OTT вызывается снова и снова из-за других советников?
Назовите мне действующее, программируемое правило! Я не вижу ни одного, и это в финансовом программном обеспечении для профессионального использования. Это бегство.
Неужели так сложно(?) хотя бы(!) всегда(!) отправлять MqlTradeRequest, когда советник его заполнил(!)?
Как советник теперь должен найти свой ордер?
Как советник теперь должен найти свой ордер? MagicNumber отсутствует в MqlTradeTransaction. Символ отсутствует в MqlTradeResult. ...
Очень часто две из трех структур OTT не заполнены (=все нули).
Неужели так сложно(?) хотя бы(!) всегда(!) отправлять MqlTradeRequest, когда советник его заполнил(!)?
Согласен. Заполнение MqlTradeTransaction весьма запутанно(не продумано).
MqlTradeTransaction работает.
Для того, чтоб получить в этой функции нужные данные, приходится попотеть :)
Вот журнал OTT-вызовов лимитного ордера на покупку, который становится лимитным ордером и закрывается TP.
В 17:00 OTT с транзакцией X:PLACED[1], а затем X:STARTED[0]
В 19:57 срабатывает стоп => ТОЛЬКО ОДИН вызов ОТТ: X:PLACED[1]
В 12:20 срабатывает лимит (отложенный ордер становится открытой позицией OTT вызывается 3 раза: X:STARTED[0], X:FILLED[4], X:FILLED[4]
В 15:42 срабатывает ТП => 3 вызова ОТТ: X:STARTED[0], X:FILLED[4], X:FILLED[4]
Как ОТТ может заранее знать, сколько раз он будет вызываться дополнительно после первого звонка??
Это с 19:57 единственный вызов сработавшего отложенного ордера:
p#0(x) означает pos.ID=0 и «эту» позицию нельзя выбрать (x), => ОК, правильно
o#2(x) означает order.ID=2 и этот порядок можно выбрать (x) => ??????
должен быть(!!) либо открытый стоп-лимитный ордер, либо лимитный ордер!!
Вот мой журнал;
Here is the log of OTT calls of a buy stop limit order that becomes a limit order and is closed by TP.
At 17:00 OTT with trans X:PLACED[1] and then X:STARTED[0]
At 19:57 the stop is triggered => ONLY ONE call of OTT: X:PLACED[1]
At 12:20 the limit is triggered (pend. order becomes an open position OTT is called 3 times: X:STARTED[0], X:FILLED[4], X:FILLED[4]
At 15:42 TP is triggered => 3 calls of OTT: X:STARTED[0], X:FILLED[4], X:FILLED[4]
How can OTT in advance know how many times it will be called additionally after the first call ??
This from 19:57 the only call of the triggered pending order:
p#0(x) means pos.ID=0 and "this" position is not selectable (x), => OK, correct
o#2(x) means order.ID=2 and this order is selectable (x) => ??????
there must be(!!) either an open stop limit order or a limit order !!
m>0< means no mag number available
Here my log;
How can OTT be used to get the information about what has happened to which orders and/or positions of an EA, if other EAs with other symbols even the same symbol are trading as well ??
BTW: Here: "nOTT:9" I counted the numbers of calls of OTT: 9 times, for 1) sending a buy stop limit, being noticed for the 2 triggers 2+3) and the exit at TP 4) which makes only 4 calls that would need!
Как можно использовать OTT для получения информации о том, что произошло с ордерами и/или позициями советника, если другие советники с другими символами, даже с тем же самым символом, также торгуют?
BTW: Здесь: "nOTT:9" Я подсчитал количество вызовов OTT: 9 раз, для 1) отправки лимита buy stop, будучи замеченным для 2 триггеров 2+3) и выхода на TP 4), что составляет всего 4 вызова, которые должны были бы!
Вот журнал OTT-вызовов лимитного ордера на покупку, который становится лимитным ордером и закрывается TP.
Мне сложно представить человека, который будет читать дальше этого предложения.
Нужно менять форму подачи сообщений, иначе просто потеряете свое время.
Мне сложно представить человека, который будет читать дальше этого предложения.
Нужно менять форму подачи сообщений, иначе просто потеряете свое время.
Как еще я могу показать проблематичный способ, с помощью которого функция OnTradeTransaction предстает перед нами, трейдерами? Слишком много звонков с отсутствующей информацией!
How else can I show the problematic way in which the OnTradeTransaction function presents itself to us traders? Too many calls with missing information!
На странице пользователя в разделе Все сообщения из превью сообщений, похоже, фильтруются некоторые символы (в частности, "<"), что портит сообщение.
Полное сообщение в топике
Его превью на странице Все сообщения
Позиция закрылась по стоплосу, притом что цена не доходила до стопа, это вообще как возможно?
Расширение спреда на ролловере. Посмотрите Ask-цену в тиковой истории.
Некоторые специально отключают стопы на время ролловера. Посмотрите историю спреда.