Организация цикла перебора ордеров - страница 11
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Впрочем, так лучше не делать - всё должно быть на своих местах.
В в таймере советника берём список по нужным критериям и при list.Total()>xxx делаем что задумано.
Получается, что в старом MQL4, где не было таймера, задача не имела решения? Зачем огород с таймером, когда решается в несколько строк?
Именно это я и смотрел.
И мой пост
И ещё, какой такой глубокий смысл в реальной торговле беспрерывно гонять цикл перебора ордеров? Самое главное впустую...
Чтобы иметь всегда актуальную информацию по торговому окружению, и не искать каждый раз при необходимости, а обращаться к имеющимся спискам. А раз списки должны быть актуальны всегда, то и стоит озаботиться их постоянным, но эффективным обновлением.
Ведь если у тебя нет списков, то придётся при надобности искать информацию. И не один раз на тике. И тут проявятся все тормоза при неоднократной загрузке окружения.
Хотя и тут можно оптимизировать - если отказаться от контроля за изменением окружения и заполнять списки только по необходимости. Но тогда ты потеряешь возможность реакции советника на действия пользователя по ручному закрытию/изменению/открытию.
Получается, что в старом MQL4, где не было таймера, задача не имела решения? Зачем огород с таймером, когда решается в несколько строк?
Вот когда не было такой возможности - тогда и нужно было думать как это решать. Но сейчас-то она есть - возможность ;)
Чтобы иметь всегда актуальную информацию по торговому окружению, и не искать каждый раз при необходимости, а обращаться к имеющимся спискам. А раз списки должны быть актуальны всегда, то и стоит озаботиться их постоянным, но эффективным обновлением.
Ведь если у тебя нет списков, то придётся при надобности искать информацию. И не один раз на тике. И тут проявятся все тормоза при неоднократной загрузке окружения.
Хотя и тут можно оптимизировать - если отказаться от контроля за изменением окружения и заполнять списки только по необходимости. Но тогда ты потеряешь возможность реакции советника на действия пользователя по ручному закрытию/изменению/открытию.
Вот ключевое слово "но эффективным". И какой такой глубокий смысл обновлять список каждую миллисекунду, если измениться список может только при поступлении очередного тика? И почему не один раз на тике? Разве может закрыться ордер вне тика? Как я понимаю, даже если и нет тика, а советник посылает команду на открытие\закрытие , то-есть на изменение окружения, то-бишь списка, то это действие породит тик. Или если не так, то уж без прихода тика порождённого чем-то другим, список не будет изменён. Разве не так?
Вот ключевое слово "но эффективным". И какой такой глубокий смысл обновлять список каждую миллисекунду, если измениться список может только при поступлении очередного тика? И почему не один раз на тике? Разве может закрыться ордер вне тика? Как я понимаю, даже если и нет тика, а советник посылает команду на открытие\закрытие , то-есть на изменение окружения, то-бишь списка, то это действие породит тик. Или если не так, то уж без прихода тика порождённого чем-то другим, список не будет изменён. Разве не так?
В тестере запускю OnTimer(), в котором идёт создание списков как раз из OnTick(), а вот в реале - тебе ж нет разницы...
Зато там таймер нужен не только для создания списков. В общем - за раз всё нужное. Пока так. Далее профилирование покажет узкие места.
Вот ключевое слово "но эффективным". И какой такой глубокий смысл обновлять список каждую миллисекунду, если измениться список может только при поступлении очередного тика? И почему не один раз на тике? Разве может закрыться ордер вне тика? Как я понимаю, даже если и нет тика, а советник посылает команду на открытие\закрытие , то-есть на изменение окружения, то-бишь списка, то это действие породит тик. Или если не так, то уж без прихода тика порождённого чем-то другим, список не будет изменён. Разве не так?
Смысл перебора таймером есть, если программа работает со многими символами - тики приходят в разное время.
Но вот перебирать "не свой" список ордеров, а созданный терминалом - нет смысла, из-за этого и проблемы, что список изменяется кем-то другим.
Смысл перебора таймером есть, если программа работает со многими символами - тики приходят в разное время.
Но вот перебирать "не свой" список ордеров, а созданный терминалом - нет смысла, из-за этого и проблемы, что список изменяется кем-то другим.
На случай "не свой" список существует общее количество ордеров которое можно хранить в статической переменной и по мере изменения запускать цикл на переборку окружения. Но не каждую-же миллисекунду...
На случай "не свой" список существует общее количество ордеров которое можно хранить в статической переменной и по мере изменения запускать цикл на переборку окружения. Но не каждую-же миллисекунду...
Срабатывание отложки таким образом не отловить.
Срабатывание отложки таким образом не отловить.
Так разговор-то не о ловле блох то-есть отложки, а о переборе всех ордеров каждую миллисекунду.
Так разговор-то не о ловле блох то-есть отложки, а о переборе всех ордеров каждую миллисекунду.
- Для чего нужна сковорода?
- Например для того, чтобы яичницу пожарить.
- так разговор-то не о яичнице, а о сковороде...