Обсуждение статьи "Библиотека для простого и быстрого создания программ для MetaTrader (Часть XXVII): Работа с торговыми запросами - выставление отложенных ордеров" - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Не я не хочу общаться по теме, а вы не поняли суть этой темы.
Вы решили, что я не понимаю, что на каждый тип отложенного запроса нужно свое решение. У всех запросов свои свойства и общее решение невозможно. Для ордеров одно решение, для повторного запроса каких то данных - другое. В последних двух статьях идет обкатка решения для ордеров. Следующая тоже будет об этом. Мое мнение - слишком растянуто получается.
3 статьи для решения отложенного запроса ТОЛЬКО ордеров, две из которых ничего не завершают... При том, что по факту (а не по форме) решение отложенного запроса ордеров совсем легкое.
Вы решили, что я не понимаю, что на каждый тип отложенного запроса нужно свое решение. У всех запросов свои свойства и общее решение невозможно. Для ордеров одно решение, для повторного запроса каких то данных - другое. В последних двух статьях идет обкатка решения для ордеров. Следующая тоже будет об этом. Мое мнение - слишком растянуто получается.
3 статьи для решения отложенного запроса ТОЛЬКО ордеров, две из которых ничего не завершают... При том, что по факту (а не по форме) решение отложенного запроса ордеров совсем легкое.
Про "невозможно" вы поторопились.
Именно, что невозможно. Разные объекты-запросы - разные свойства. В одном объекте-запросе все свойства не вставить.
Меня просто удивляет, как по факту простую задачу можно решать на протяжении полутора месяцев в трех статьях. Если этот метод программирования считается "эффективным", то я рад что программирую иначе.
Все обращения советника к серверу отследить невозможно.
Спрашиваю, потому что решение задачи повторной отсылки сорвавшихся ордеров (очевидно) не требует усложнения и решается просто.
Если ордера отсылаются не методами библиотеки, то всю торговую логику нужно писать самостоятельно. Библиотека предоставляет возможность этого не делать, но не принуждает всё делать через её функционал.
В такой ситуации библиотека не может управлять не своими торговыми функциями. Но она сможет сообщить о факте успешного торгового запроса, отправленного через сторонние функции.
Пользоваться функционалом библиотеки, где предусмотрена реакция на ошибки, возвращаемые сервером, и сделана их адекватная обработка.
А что видится вам в качестве обработчика кодов возврата сервера?
Именно, что невозможно. Разные объекты-запросы - разные свойства. В одном объекте-запросе все свойства не вставить.
Меня просто удивляет, как по факту простую задачу можно решать на протяжении полутора месяцев в трех статьях. Если этот метод программирования считается "эффективным", то я рад что программирую иначе.
Объекты - отложенные торговые запросы. Вся информация о любых торговых запросах хранится в единой для всех запросов структуре - MqlTradeRequest.
Вы так троллите?
По факту я описываю концепцию. По шагам. В статьях (пишу тексты самостоятельно, проверяю на ошибки по три-четыре раза, и то упускаю некоторые). Озвучиваю содержание концепции в статьях, логику и функционал, показываю как это сделать. При этом предварительно обдумываю различные варианты, дюжая часть которых выбрасывается в корзину - т.е., по факту, я пишу кода раза в три-четыре больше, чем есть в статьях. Иногда весь код полностью переписываю с нуля, и по иным принципам. Затем я всё тестирую в тестере и на демо - то, что описано в каждой статье. И то получается упускать некоторые баги, и потом - в следующих статьях - их править.
Если код заработал с первого раза - значит в нём зарыта бомба, и ждите в дальнейшем большой сюрприз.
Я удивлён, что вы пишете для себя всё за час. Без проверок, без тестирования, и лишь бы шевелилось :)
Очень хочу понять, что вы считаете простым здесь. Почему не хотите понять, что это часть будущего функционала других частей библиотеки, и всё заранее нужно увязать "в уме" с тем, чего ещё нету, но запланировано?
Я не ставлю задачу один раз сделать, и забросить в свободное плавание. У меня иная задача - продумать как дальше всё будет взаимосвязано. На это требуется время, и некий подход решения. Если для вас он сложен, то что ж... Значит сложен...
...
А что видится вам в качестве обработчика кодов возврата сервера?
Я вам покажу короткое и эффективное решение.
1. Объявляем глобальную переменную: string Del_req;
2. Пишем функцию void Delayed_request(). Функция будет вызываться из OnTimer() раз в секунду (если Del_req != NULL).
3. Каждой торговой функции отсылающей ордер добавляем параметр int delayed_request_ID = 0
4. Каждый торговый запрос возвращает ответ сервера. Если delayed_request = 0 (не повторный вызов из Delayed_request() ) и ответ сервера требует повтора запроса, торговые функции пишут все параметры вызова в переменную Del_req (через два разделителя - delayed_request_ID и параметров) и в конце строки добавляют количество нужных попыток (например 10).
5. Функция Delayed_request() раз в секунду проверяет строку Del_req. Если строка не NULL, функция помещает ее в массив и делает по ней цикл поиска подстроки вызова, находит, вычленяет его из общей строки, разбивает, смотрит на тип вызова и передает параметры в нужную торговую функцию вместе с delayed_request_ID. Далее, смотрит на счетчик вызовов и уменьшает его на единицу. Если после вычитания единицы счетчик ноль - стирает всю подстроку вызова из общей строки Del_req.
6. Если торговая функция принимает вызов с delayed_request_ID и запрос к серверу оказался удачным, она стирает подстроку вызова из общей строки Del_req (находит его по delayed_request_ID).
Все это можно сделать за один день и применять не только к торговым, но и к любым запросам.
ЗЫ. Никакого троллинга нет, я действительно удивляюсь неочевидности простых решений для матерых программистов.
Я вам покажу короткое и эффективное решение.
1. Объявляем глобальную переменную: string Del_req;
2. Пишем функцию void Delayed_request(). Функция будет вызываться из OnTimer() раз в секунду.
3. Каждой торговой функции отсылающей ордер добавляем параметр int delayed_request_ID = 0
4. Каждый торговый запрос возвращает ответ сервера. Если delayed_request = 0 (не повторный вызов из Delayed_request() ) и ответ сервера требует повтора запроса, торговые функции пишут все параметры вызова в переменную Del_req (через два разделителя - delayed_request_ID и параметров) и в конце строки добавляет количество нужных попыток (например 10).
5. Функция Delayed_request() раз в секунду проверяет строку Del_req. Если строка не NULL, функция помещает ее в массив и делает по ней цикл поиска вызова, находит, вычленяет его из общей строки, разбивает, смотрит на тип вызова и передает параметры в нужную торговую функцию вместе с delayed_request_ID. Далее, смотрит на счетчик вызовов и уменьшает его на единицу. Если счетчик не ноль, в строке вызовов Del_req меняет счетчик вызова на значение меньшее на единицу, если ноль - стирает всю строку вызова из общей строки Del_req.
6. Если торговая функция принимает вызов с delayed_request_ID и запрос к серверу оказался удачным, она стирает подстроку вызова из общей строки Del_req (находит его по delayed_request_ID).
Все это можно сделать за один день и применять не только к торговым, но и к любым запросам.
ЗЫ. Никакого троллинга нет, я действительно удивляюсь неочевидности простых решений для матерых программистов.
Сознательно толкать тормоза в методы?
А чем отличается предложенный способ от того, который делается? Кроме того, что работать придётся через дорогостоящие функции работы со строками? Да концептуально ничем. Поэтому - будет так, как задумано. Тем более, что дальше то, что делается, и пока вам неведомо, будет использоваться для расширения функционала работы с отложенными запросами.
Сознательно толкать тормоза в методы?
А чем отличается предложенный способ от того, который делается? Кроме того, что работать придётся через дорогостоящие функции работы со строками? Да ничем. Поэтому - будет так, как задумано. Тем более, что дальше то, что делается, и пока вам неведомо, будет использоваться для расширения функционала работы с отложенными запросами.
Делайте как считаете нужным. Это ваше творчество. Я высказал мнение.
И никаких тормозов нет. Отложенные запросы все равно раз в секунду отправляются.
ЗЫ. Отличается тем, что отложенные запросы не превращаются в полноценные Объекты и тем самым не тянут за собой портянки кода.
Делайте как считаете нужным. Это ваше творчество. Я высказал мнение.
И никаких тормозов нет. Отложенные запросы все равно раз в секунду отправляются.
Зачем они отсылаются раз в секунду? Торговый сервер заспамить?
ЗЫ. Отличается тем, что отложенные запросы не превращаются в полноценные Объекты и тем самым не тянут за собой портянки кода.
А мне для реализации задуманного далее как раз нужны полноценные объекты. Но вы-то пока об этом не в курсе, и пытаетесь предлагать неэффективные для дальнейшей работы способы решения малой части поставленной задачи. А тут всё увязано воедино, и общая концепция одинакова - от этой малой части зависят остальные запланированные в дальнейшем вещи.
Впрочем, спасибо за ваше мнение - любое мнение полезно и имеет смысл.
ЗЫ. И, да - не страшно написать рабочую, расширяемую и совместимую портянку кода, нежели постоянно переписывать под очередные задачи ранее бездумно написанные неполноценные решения.