Функция OrderSendAsync() - страница 7

 

Асинхронность без контроля = хаос.

Контроль асинхронности можно будет выполнить только в OnTrade().

Возникает необходимость идентификации конкретного запроса в OnTrade().

Таким образом, приходим к тому, что OrderSendAsync() должно возвращать номер тикета, полученного от сервера (исключаем ситуацию с тайм-аутом). Номер тикета нужен для однозначной идентификации запроса и у сервера, и у клиента.

Унифицируя данный механизм, можно и функции OrderSend() также переделать - возвращать номер тикета, либо "-1" в случает неудачи отправки ордера на сервер.

 

Далее, в программе реализовать класс с перечнем сгенерированных тикетов.

При каждом событии OnTrade() понимаем:

1. А вообще, это наше действие, или, например, действие другого экземпляра эксперта (маджики уже не потребуются).

2. На какой именно запрос получаем ответ. 

Документация по MQL5: Торговые функции / OrderSend
Документация по MQL5: Торговые функции / OrderSend
  • www.mql5.com
Торговые функции / OrderSend - Документация по MQL5
 
voix_kas:

Таким образом, приходим к тому, что OrderSendAsync() должно возвращать номер тикета, полученного от сервера (исключаем ситуацию с тайм-аутом). Номер тикета нужен для однозначной идентификации запроса и у сервера, и у клиента.

Здрасьте. Вкурсе вообще что такое асинхронность?
 
TheXpert:
Здрасьте. Вкурсе вообще что такое асинхронность?
<<Даёшь синхронную асинхронность!>>
 
Сейчас обсуждаем добавление функции OnTradeResult(MqlTradeResult &info), которая будет иметь точные детали по ответам сервера.
Документация по MQL5: Стандартные константы, перечисления и структуры / Структуры данных / Структура результата торгового запроса
Документация по MQL5: Стандартные константы, перечисления и структуры / Структуры данных / Структура результата торгового запроса
  • www.mql5.com
Стандартные константы, перечисления и структуры / Структуры данных / Структура результата торгового запроса - Документация по MQL5
 
Renat:
Сейчас обсуждаем добавление функции OnTradeResult(MqlTradeResult &info), которая будет иметь точные детали по ответам сервера.

На моё имхо, со стороны пользователя должно выглятеть так:

пользователь пишет класс работы с указателями и прикручивает к нему класс обработки торгового сигнала.

Появился сигнал(ы) создаются новые объекты и отправляется запрос(ы) на сервер, соответственно объект существует до исполнения сигнала.

в OnTrade отслеживается судьба и принимается решение (или/или) или отправляем новый запрос или уничтожаем объект тк он своё отработал.

В этой схеме нужна идентификация какой объект обрабатывать в связи с данной активацией события Trade.

 
Urain:

В этой схеме нужна идентификация какой объект обрабатывать в связи с данной активацией события Trade.

А в чем проблема?
 
TheXpert:
А в чем проблема?

Стебаешься?

Trade сейчас безликий, по нему нельзя определить какой объект из списка следует обрабатывать в с вязи с его приходом.

 
Urain:

Стебаешься?

Отнюдь. Между прочим заморачиваться на OnTrade сильно не стоит, т.к. он не будет приходить в 100% случаев (это примерно аналогично ошибке 1 в МТ4)

Т.е. все равно надо делать страховку.

Так не лучше ли сразу "сделать все хорошо" (с) ?

 
TheXpert:

Отнюдь. Между прочим заморачиваться на OnTrade сильно не стоит, т.к. он не будет приходить в 100% случаев (это примерно аналогично ошибке 1 в МТ4)

Т.е. все равно надо делать страховку.

Так не лучше ли сразу "сделать все хорошо" (с) ?

Обоснуй, почему Trade не будет приходит в ~100% случаев?
 
Urain:
Обоснуй, почему Trade не будет приходит в ~100% случаев?
Потому что битые пакеты, обрывы связи и т.п. хрень. Ненадежно. Ненадежно -- надо отвязываться.