Ожидание выполнения функции OrderClose()

Если ты не хочешь ждать, значит результат выполнения этой функции тебя не интересует. В таком случае могу рекомендовать просто не включать эту функцию в свой код.

Спасибо, но

если возможно, нужен ответ по существу вопроса:

- алгоритму действительно "НЕ" важен результат операции, т.к.

- важнее выполнить следующие операции.

Пжл, может к.л. порекомендовать способы продолжить выполнение кода

БЕЗ ожидания кода возврата от функции?

Единственный возможный вариант уже был озвучен, и он по существу. Используйте стоп-лоссы и тейк-профиты. Тогда OrderClose() будет не нужен. Других альтернатив (кроме смены ДЦ, хотя этот ДЦ наверняка тоже сначала нормально отрабатывал ваши запросы) у вас нет.

Постараюсь объяснить еще раз:

- неважнно какая функция используется OrderClose() или OrderSend() [в последней указаны SL и TP],

- проблема даже не в скорости ответа ДЦ [хотя конечно это исходная причина при лобовом решении задачи],

НУЖНО ПРОДОЛЖИТЬ ВЫПОЛНЕНИЕ КОДА НЕ ДОЖИДАЯСЬ ВОЗРАТА КОДА ЗАВЕРШЕНИЯ ФУНКЦИИ

Подскажите пжл как этого добиться.

Алгоритму, как я понимаю, вообще всё пофигу, а вот инвестору, как мне почему-то думалось, должно быть важно закрылась его сделка или нет.

В MQL4 нет механизмов асинхронного выполнения кода. Поэтому ответ касательно MQL4 - НИКАК.

Задачу можно решить, написав основной код на С++ (или любом другом языке программирования, позволяющим асинхронное выполнение отдельных участков кода) и грамотно организовав взаимодействие между ним и экспертом на MQL4.

bstone, спасибо, что-то подоюное и предполагал, задавая вопрос.

Подскажите пжл, где взять такие библиотеки?

(предполагаю, что существуют библиотеки с функциями постановки и снятия ордеров для платформы МТ)

или

примеры такой реализации?

Еще раз спасибо.

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

Предположу, что Вы собираете тики, поэтому откройте еще один такой же график и установите на него отдельно собиратель тиков, тогда ему первый советник мешать не будет.

Мэтры уже высказались, теперь очередь обывателей с банальными рассуждениями.

Банальная схема сводится к двум советникам и передатчику информации между ними.

1-й советник (головной) считает, принимает решения и отдает виртуальные приказы на открытие/закрытие позиций, записывая эти приказы в глобальные переменные или промежуточный файл.

Он не обращается к ДЦ и не ждет от него ответа, т.е. асинхронен, как и требовалось.

2-й советник (исполнитель приказов) читает виртуальные приказы из глобальных переменных или промежуточного файла, формализует и отсылает их ДЦ в необходимом виде.

При необходимости, второй советник таким же образом может передавать первому информацию о результатах выполнения операций.

Советники стоят на одном терминале каждый в своем окне.

И чем такая схема Вас не устраивает?