У меня проблема с "ArrayCopyRates"
Поставив обработчик ошибок, Вы забыли про асинхронность процессов и сразу же пытаетесь проверять буфер, хотя данные еще не пришли.
Если бы это был не индикатор, а скрипт, на после отлова кода 4066 можно было бы поставить задержку на пару секунд Sleep(2000) и снова попробовать запросить данные. Но в случае индикатора задержки не действуют и лучше всего при отсутствии данных других символов не рисовать свой индикатор, а заполнять его нулями. А на следующих тиках снова проверите наличие данных другого символа и построите свой индикатор.
То есть, в индикаторах, которые строятся на основе других графиков, при их отсутствии необходимо не рассчитывать свой индикатор, а выходить и ждать следующего тика. Другого пути нет. Запросы истории асинхронны и терминал не будет блокировать свою работу (а тем более расчет текущих индикаторов) в ожидании гарантированного прихода данных еще не загруженных графиков.
Если бы это был не индикатор, а скрипт, на после отлова кода 4066 можно было бы поставить задержку на пару секунд Sleep(2000) и снова попробовать запросить данные. Но в случае индикатора задержки не действуют и лучше всего при отсутствии данных других символов не рисовать свой индикатор, а заполнять его нулями. А на следующих тиках снова проверите наличие данных другого символа и построите свой индикатор.
То есть, в индикаторах, которые строятся на основе других графиков, при их отсутствии необходимо не рассчитывать свой индикатор, а выходить и ждать следующего тика. Другого пути нет. Запросы истории асинхронны и терминал не будет блокировать свою работу (а тем более расчет текущих индикаторов) в ожидании гарантированного прихода данных еще не загруженных графиков.
Проблемка такая-же... пытаюсь разузнать, но похоже разработчики
забыли предусмотреть явную функцию запроса на обновление истории.
.. Есть iBarShift- поиск смещения по времени, но если бара нет, он возвращает 0
и в last_error тоже 0 :-((( Читал я твою тему, интересный вариант, но
я пошел чуток дальше. Сравниваю "EURUSD" и "EURJPY" по перекупленности/перепроданности
индикатором Williams Percent. если умножить его процент отклонения(берем
отклонение от 50) на фактическое колебание курса(пронормировать)
для обоих пар, а потом сложить, то можно получить результирующую
величину отклониния "USDJPY" в пунктах от текущего курса.
но пока работет не очень, точность плоховатая... направление
отклонения определяет, а с величиной ошибается...
Renat:
Поставив обработчик ошибок, Вы забыли про асинхронность процессов и сразу же пытаетесь проверять буфер, хотя данные еще не пришли.
-Это была "нарезка", в орининале я вставил задержку и догадался, о том, что Вы пишете дальше
Если бы это был не индикатор, а скрипт, на после отлова кода 4066 можно было бы поставить задержку на пару секунд Sleep(2000) и снова попробовать запросить данные. Но в случае индикатора задержки не действуют и лучше всего при отсутствии данных других символов не рисовать свой индикатор, а заполнять его нулями. А на следующих тиках снова проверите наличие данных другого символа и построите свой индикатор.
- К сожалению, суть решаемой мною задачи, требует жесткой синхронизации по времени всех пар, а, собственно, Нули являются для этой системы "злом". Видимо поэтому представители MetaQuotes рекомендовали на форуме с https://www.metaquotes.net/ru/ AlexSilver'у для решения этой задачи пользоваться скриптами, не объяснив этот нюанс.
То есть, в индикаторах, которые строятся на основе других графиков, при их отсутствии необходимо не рассчитывать свой индикатор, а выходить и ждать следующего тика. Другого пути нет. Запросы истории асинхронны и терминал не будет блокировать свою работу (а тем более расчет текущих индикаторов) в ожидании гарантированного прихода данных еще не загруженных графиков.
- Жаль. Сейчас я применяю решение, описанное в моем посте, а именно переключаюсь на другой ТаймФрейм и обратно, но хотелось бы "по красивше". Бум искать "недокумментированные решения" :)
Просто "алгоритмический" обход этого нюанса "...а выходить и ждать следующего тика..." так заморачивает исходный код, что аж оторопь берет и хочется найти обходной путь, который заставил бы один раз, сразу после запуска терминала "качнуть историю". Наверное попробую вариант с запуском отдельного скрипта/индикатора, в котором будут тупо iClose по всем парам, который бы инициализировал бы эту закачку.
Запросы истории асинхронны и терминал не будет блокировать свою работу (а тем более расчет текущих индикаторов) в ожидании гарантированного прихода данных еще не загруженных графиков.
- Кстати из своих наблюдений: А не это ли является причиной подвисания MT ("...будет блокировать свою работу..."), если код, подобный прикрепленному, поместить в блок init()? (На 56 парах с подобным блоком в init(), я просто ни разу не дожидался "отвисания" MT, поэтому и перенс его в start(), а там :(
Поставив обработчик ошибок, Вы забыли про асинхронность процессов и сразу же пытаетесь проверять буфер, хотя данные еще не пришли.
-Это была "нарезка", в орининале я вставил задержку и догадался, о том, что Вы пишете дальше
Если бы это был не индикатор, а скрипт, на после отлова кода 4066 можно было бы поставить задержку на пару секунд Sleep(2000) и снова попробовать запросить данные. Но в случае индикатора задержки не действуют и лучше всего при отсутствии данных других символов не рисовать свой индикатор, а заполнять его нулями. А на следующих тиках снова проверите наличие данных другого символа и построите свой индикатор.
- К сожалению, суть решаемой мною задачи, требует жесткой синхронизации по времени всех пар, а, собственно, Нули являются для этой системы "злом". Видимо поэтому представители MetaQuotes рекомендовали на форуме с https://www.metaquotes.net/ru/ AlexSilver'у для решения этой задачи пользоваться скриптами, не объяснив этот нюанс.
То есть, в индикаторах, которые строятся на основе других графиков, при их отсутствии необходимо не рассчитывать свой индикатор, а выходить и ждать следующего тика. Другого пути нет. Запросы истории асинхронны и терминал не будет блокировать свою работу (а тем более расчет текущих индикаторов) в ожидании гарантированного прихода данных еще не загруженных графиков.
- Жаль. Сейчас я применяю решение, описанное в моем посте, а именно переключаюсь на другой ТаймФрейм и обратно, но хотелось бы "по красивше". Бум искать "недокумментированные решения" :)
Просто "алгоритмический" обход этого нюанса "...а выходить и ждать следующего тика..." так заморачивает исходный код, что аж оторопь берет и хочется найти обходной путь, который заставил бы один раз, сразу после запуска терминала "качнуть историю". Наверное попробую вариант с запуском отдельного скрипта/индикатора, в котором будут тупо iClose по всем парам, который бы инициализировал бы эту закачку.
Запросы истории асинхронны и терминал не будет блокировать свою работу (а тем более расчет текущих индикаторов) в ожидании гарантированного прихода данных еще не загруженных графиков.
- Кстати из своих наблюдений: А не это ли является причиной подвисания MT ("...будет блокировать свою работу..."), если код, подобный прикрепленному, поместить в блок init()? (На 56 парах с подобным блоком в init(), я просто ни разу не дожидался "отвисания" MT, поэтому и перенс его в start(), а там :(
Romic:
Проблемка такая-же... пытаюсь разузнать, но похоже разработчики забыли предусмотреть явную функцию запроса на обновление истории. ..
- Если я правильно понял их (MQ) недавние ответы на подобные выпады, то это их принципиальная позиция.
Читал я твою тему, интересный вариант, но я пошел чуток дальше. Сравниваю "EURUSD" и "EURJPY" по перекупленности/перепроданности индикатором Williams Percent. если умножить его процент отклонения(берем отклонение от 50) на фактическое колебание курса(пронормировать) для обоих пар, а потом сложить, то можно получить результирующую величину отклониния "USDJPY" в пунктах от текущего курса. но пока работет не очень, точность плоховатая... направление отклонения определяет, а с величиной ошибается...
- В данный момент мы сошлись с AlexSilver'ом, и пока акцентируем внимание, именно на том, чтобы записать "рассчитанные результаты" в хистори. Он - для работы с этими данными в режиме офф-лайн (с накладыванием на них и анализом его любимого Ишимоку), я - как единственную возможность переброски "почти оннлайновых данных" в третью систему для дальнейшего анализа.
После решения подобной (технической!!!) проблемы, по крайней мере я, сконцентрирую внимание на собственно разных вариантах расчетов разных индексов, которые, как мне кажется проще считать в MT, а обрабатывать вне его (просто в более узкоспециализированных системах - фраза только для того, чтобы не сподвигнуть MQ на ответы в защиту :) ). Именно поэтому я и заморочился с созданием инклуда и предоставлением хоть какого-то интерфейса для "написания формул".
...но пока работет не очень, точность плоховатая...
- Вот поэтому я и хочу "синхронизировать данные", в твоем примере 3х пар, а потом уже, например, открыв оффлайновые графики и произвести "обсчет" или найти третью систему, в которой можно И реализовать твою идею И произвести ...подбор... пар для твоей идеи (например, почему ты остановился на этих 3х парах: они лучше коррелируют или "пальцем в небо". Вопрос риторический, т.е. я эту тему продолжать не буду ;) ). - Это своеобразный ответ на замечание Renat'а о том, почему НЕ НУЖНО заполнять "дырки"!
Вот.
Проблемка такая-же... пытаюсь разузнать, но похоже разработчики забыли предусмотреть явную функцию запроса на обновление истории. ..
- Если я правильно понял их (MQ) недавние ответы на подобные выпады, то это их принципиальная позиция.
Читал я твою тему, интересный вариант, но я пошел чуток дальше. Сравниваю "EURUSD" и "EURJPY" по перекупленности/перепроданности индикатором Williams Percent. если умножить его процент отклонения(берем отклонение от 50) на фактическое колебание курса(пронормировать) для обоих пар, а потом сложить, то можно получить результирующую величину отклониния "USDJPY" в пунктах от текущего курса. но пока работет не очень, точность плоховатая... направление отклонения определяет, а с величиной ошибается...
- В данный момент мы сошлись с AlexSilver'ом, и пока акцентируем внимание, именно на том, чтобы записать "рассчитанные результаты" в хистори. Он - для работы с этими данными в режиме офф-лайн (с накладыванием на них и анализом его любимого Ишимоку), я - как единственную возможность переброски "почти оннлайновых данных" в третью систему для дальнейшего анализа.
После решения подобной (технической!!!) проблемы, по крайней мере я, сконцентрирую внимание на собственно разных вариантах расчетов разных индексов, которые, как мне кажется проще считать в MT, а обрабатывать вне его (просто в более узкоспециализированных системах - фраза только для того, чтобы не сподвигнуть MQ на ответы в защиту :) ). Именно поэтому я и заморочился с созданием инклуда и предоставлением хоть какого-то интерфейса для "написания формул".
...но пока работет не очень, точность плоховатая...
- Вот поэтому я и хочу "синхронизировать данные", в твоем примере 3х пар, а потом уже, например, открыв оффлайновые графики и произвести "обсчет" или найти третью систему, в которой можно И реализовать твою идею И произвести ...подбор... пар для твоей идеи (например, почему ты остановился на этих 3х парах: они лучше коррелируют или "пальцем в небо". Вопрос риторический, т.е. я эту тему продолжать не буду ;) ). - Это своеобразный ответ на замечание Renat'а о том, почему НЕ НУЖНО заполнять "дырки"!
Вот.
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
При написании довольно "навернутого" индикатора возникла "плавающая проблема", которую я смог локализовать в несколько строк прикрепленного индикатора.
Суть - я пытаюсь считать для дальнейшей "обработки" "данные баров текущего графика" (ArrayCopyRate), Прочитав комментарий про "данные "чужого" инструмента и/или таймфрейма", я вставил подобный обработчик в надежде на то, что в "этом случае в переменную last_error будет помещена ошибка ERR_HISTORY_WILL_UPDATED (4066 - запрошенные исторические данные в состоянии обновления) и необходимо через некоторое время повторить попытку копирования."
Однако, однако....
Если индикатор повесить на любой чарт с символом, отличным от AUDCAD (например, EURUSD, M5), то в первом логе будет присутствовать ошибка 4066, а при печати остальных "попыток", ошибка будет 0, но данные будут .....Хм... "устаревшими". Если поменять, например, таймфрейм того чарта, на котором висел индюк (на новом "ТаймФрейме" тоже будет ошибка), а потом вернуться назад, то...... ошибка пропадет и с первой попытки будут прочтены нужные данные. Короче Опс. (Подчеркиваю - мы "манипулирем" с Парой EURUSD, AUDCAD как был "не открыт", так и не открывался!!!!)
Убедительная просьба не предлагать в качестве решения:
- держать чарт символа из параметров ArrayCopyRate "открытым", т.к. в работе "оригинального" инидикатора используется большое количество пар, в общем случае, переменное.
- заменить ArrayCopyRate на какие-нибудь функции типа iClose и пр, т.к. для оригинальном индикатора это принципиально.
Если ничего не поможет, кроме вызова с целью "инициализации" чего-нибудь типа тех же iClose, то ....., но криво.
Убедительна просьба подключиться представителей MetaQuotes, т.к. есть небольшая вероятность того, что это баг! ... или фича?, но тогда, наверное, не MT, а ДЦ?
MT4: 4.00 Build 193 (04 May 2006)
Если кого заинтересует "разработка", то ее обсуждение здесь http://forum.viac.ru/viewtopic.php?t=3950Е . Тема интересная, хотя реализация хромает. Сама идея созвучна с недавним всплеском обсуждения/обвинения "дырок", но чуть-чуть более обоснованная.