Проблема перевода с МТ4 на МТ5. Или, точнее, невозможность без'ошибочного исполнения некоторых алгоритмов в МТ5. - страница 7
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Бред — в организации своей копии данных, которые и так доступны в терминале.
Такого бреда много. При выпуске МТ4 в августе 2005 года появился индикатор ZigZag. Ошибок там немеряно. Он в одном экземпляре тогда на быстром рынке мог подвешивать терминал. И часто выводил экстремумы в воздухе, не привязанные к минимумам/максимумам баров.
В одном из сообщений разработчик этого зигзага сказал что это - (прошу без эмоций воспринять дальнейшее) это проявление нечеткой логики........
Но и до сих пор, а прошло с момента вывода МТ4 14 лет, в индикаторе зигзаг есть параметр - Deviation - который не производит никаких действий. То есть какое бы значение этого параметры Вы ни задали, прорисовка зигзага на графике не изменится.
Огромное количество программ основано на этом индикаторе. Большинство разработчиков включают в свои программы этот параметр. Бестолковый параметр. И разработчики проявляют просто фантастическое безразличие к этому. Параметр, между прочим, ресурсы компьютера кушает.
И таких моментов было много по разным другим поводам.
Продолжу.
Те экстремумы зигзага, повисшие в воздухе, как раз имеют общую природу с тем, что мы имеем при доступе к таймсериям.
Просто в МТ4 отказа в доступе к таймсериям не происходило. Там какие-то функции неправильно работали (возможно, и сейчас они также работают). У меня для своего внутреннего пользования было объяснение. Также сделал принудительно по своему. И все стало работать без ошибок, без нагрузки на процессор. Даже вывод на графики нескольких десятков зигзагов не вызывал зависания терминала...
Если бы все работало, не было бы миллион тем, посвященных этой проблеме.
Просто логика оказалась сложнее, чем готовы осилить пользователи терминала.
Да и ошибки, наверняка есть, но разработчикам их искать не досуг, а из пользователей воспроизводить и доказывать тоже никто не хочет.
Андрей, я предлагаю исходить из того, что имеем. А раз имеем то, о чём ты говоришь, то лучше говорить, или всё же обойти?
Я считаю, что проблем достаточно, но чем о них из ветки в ветку говорить (что тоже полезно - иногда исправляются), а сделать в обход.
Я и предложил неплохой вариант - кэшировать нужные таймсерии в момент их полной доступности. А далее - получать от готовых и всегда доступных таймсерий все нужные данные. И только дополнять их новыми данными. При этом тогда, когда они доступны - не спеша, и не обязательно в момент, когда они требуются.
Так хотя бы дело будет двигаться. А разговоры можно и на потом оставить - когда делать нечего.
Продолжу.
Те экстремумы зигзага, повисшие в воздухе, как раз имеют общую природу с тем, что мы имеем при доступе к таймсериям.
Просто в МТ4 отказа в доступе к таймсериям не происходило. Там какие-то функции неправильно работали (возможно, и сейчас они также работают). У меня для своего внутреннего пользования было объяснение. Также сделал принудительно по своему. И все стало работать без ошибок, без нагрузки на процессор. Даже вывод на графики нескольких десятков зигзагов не вызывал зависания терминала...
Если к таймсерии отказано в доступе - значит она находится на стадии синхронизации. Нужно подождать до следующего тика.
В вашей ситуации - лучше кешировать таймсерии - они будут всегда доступны без ожиданий, и по первому же запросу.
Кэшировать в момент запуска индикатора - когда есть время на "подождать синхронизацию" и во время ожидания запросить данные следующей таймсерии.
Андрей, я предлагаю исходить из того, что имеем. А раз имеем то, о чём ты говоришь, то лучше говорить, или всё же обойти?
Я считаю, что проблем достаточно, но чем о них из ветки в ветку говорить (что тоже полезно - иногда исправляются), а сделать в обход.
Я и предложил неплохой вариант - кэшировать нужные таймсерии в момент их полной доступности. А далее - получать от готовых и всегда доступных таймсерий все нужные данные. И только дополнять их новыми данными. При этом тогда, когда они доступны - не спеша, и не обязательно в момент, когда они требуются.
Так хотя бы дело будет двигаться. А разговоры можно и на потом оставить - когда делать нечего.
Тогда уже эффективнее сделать воспроизводимый пример, чтобы разработчики исправили.
Андрей, я предлагаю исходить из того, что имеем. А раз имеем то, о чём ты говоришь, то лучше говорить, или всё же обойти?
Я считаю, что проблем достаточно, но чем о них из ветки в ветку говорить (что тоже полезно - иногда исправляются), а сделать в обход.
Я и предложил неплохой вариант - кэшировать нужные таймсерии в момент их полной доступности. А далее - получать от готовых и всегда доступных таймсерий все нужные данные. И только дополнять их новыми данными. При этом тогда, когда они доступны - не спеша, и не обязательно в момент, когда они требуются.
Так хотя бы дело будет двигаться. А разговоры можно и на потом оставить - когда делать нечего.
А почему нельзя сделать так разработчикам терминала? Все равно в момент обновления таймсерий доступа к таймсериям нет. Пусть бы для всех был бы организован доступ к этой, скажем так, кэшированной истории. Что от этого изменится? То есть чтобы никогда не было прерывания в доступе. Ну, может быть, на нулевом баре происходили бы какие-то задержки. Вся остальная история будет всегда доступна.
Я и предложил неплохой вариант - кэшировать нужные таймсерии в момент их полной доступности. А далее - получать от готовых и всегда доступных таймсерий все нужные данные. И только дополнять их новыми данными.
это плохой вариант, нужно полностью повторять логику построения и синхронизации таймсерий в терминале - то новый тик пришел, то синхронизация не закончилась...то обрыв связи
ЗЫ: да и зачем это делать? - не знаю как кто по жизни, у меня один сотовый тлф, один автомобиль и даже кошелек беру всего один с собой, но случаев то много по жизни? - нужно подстраховаться? ...."Три магнитофона, три кинокамеры заграничных, три портсигара отечественных, куртка...замшевая… Три. Куртки" )))
Если к таймсерии отказано в доступе - значит она находится на стадии синхронизации. Нужно подождать до следующего тика.
все правильно! но нужно прекратить расчеты MQL-программе в любом месте и выйти в терминал до следующего тика...я периодически предлагаю что то как в Delphi "Abort() или Halt()" - получил один раз ошибку по доступу к таймсериям - это критическая ошибка, которую нет смысла обрабатывать по много раз - все равно пока терминал не наладит взаимодействие с MQL-программой "делов не будет" )))
ЗЫ: Я не создаю эту ошибку (ошибка доступа к таймсериям) - ее создает терминал, но все MQL-программисты, должны быть готовы мастерски разгребать ошибку порожденную терминалом???... да ( когда код на пару сотен строк ) это, в принципе легко обыграть, а когда код большой и удобно было из разных участков программы использовать доступ к таймесериям - и ? и нужно плодить 999 способов выйти из любого участка программы и не потерять предыдущие расчеты? - да это возможно, но это требует четкого плана (алгоритма) по которому будет написан исходный код... а если исходник дорабатывается путем дополнения готовых функций (классов)? - т.е. нужно будет каждый раз разбираться что там внутри... трудоемкая в общем задача для больших проектов все предусмотреть, имхо
Если программа создавалась в течение 14 лет, перевести ее методом нового проектирования - проще застрелиться. А отлаживать многочисленные связи также сложно. Проверка доступности к таймфреймам дает в случае отсутствия доступа серьезные задержки. Ладно бы если включен автомат графических построений. Перестройка в режиме автомата явление нечастое. Здесь задержки можно и не заметить. Правда и в этом случае при возникновении прерывания доступа к таймсериям графические построения иногда выводятся в урезанном виде. Часть элементов успевает построиться, а часть нет... Или же происходит обрезка фрактальной фильтрацией по каким-то тф.
***
Если программа создавалась в течение 14 лет, перевести ее методом нового проектирования - проще застрелиться. А отлаживать многочисленные связи также сложно. Проверка доступности к таймфреймам дает в случае отсутствия доступа серьезные задержки. Ладно бы если включен автомат графических построений. Перестройка в режиме автомата явление нечастое. Здесь задержки можно и не заметить.
Но проблема когда производится настройка через графический интерфейс. Пользователь нажимает на кнопку и... надо ждать следующего тика. Или давить на кнопку несколько раз до возникновения желаемой реакции программы. Какова реакция пользователя?... -***
А в МТ4 таких проблем нет.
я прекрасно Вас понимаю, поэтому и решил поддержать обсуждение
ну и еще из предложений: вот добавили не так давно функции доступа к таймсериям iClose()..iXXX() - отлично!
пусть будут это синхронные функции т.е. доступ к таймсериям будет может дольше, но гарантирован на уровне терминала или ув.разработчики добавьте директиву прекомпилятора которая будет давать в MQL-программу тик лишь в том случае когда терминал готов дать доступ к историческим данным ( OHLC ) , если не готов - то нет тика, пусть эта директива прекомпилятора будет подключаемой пользователем
....
но цель одна - избавить пользователей от бесконечных проверок готовности OHLC чарта, эта проблема с момента появления МТ5 до сих пор решена только на уровне проверок внутри MQL-программы, это трудоемкий процесс и по моему пользователи ожидают от терминала без проблем и гарантированно получать в любое время, в любом участке кода данные таймсерий
это плохой вариант, нужно полностью повторять логику построения и синхронизации таймсерий в терминале - то новый тик пришел, то синхронизация не закончилась...то обрыв связи
ЗЫ: да и зачем это делать? - не знаю как кто по жизни, у меня один сотовый тлф, один автомобиль и даже кошелек беру всего один с собой, но случаев то много по жизни? - нужно подстраховаться? ...."Три магнитофона, три кинокамеры заграничных, три портсигара отечественных, куртка...замшевая… Три. Куртки" )))
все правильно! но нужно прекратить расчеты MQL-программе в любом месте и выйти в терминал до следующего тика...я периодически предлагаю что то как в Delphi "Abort() или Halt()" - получил один раз ошибку по доступу к таймсериям - это критическая ошибка, которую нет смысла обрабатывать по много раз - все равно пока терминал не наладит взаимодействие с MQL-программой "делов не будет" )))
ЗЫ: Я не создаю эту ошибку (ошибка доступа к таймсериям) - ее создает терминал, но все MQL-программисты, должны быть готовы мастерски разгребать ошибку порожденную терминалом???... да ( когда код на пару сотен строк ) это, в принципе легко обыграть, а когда код большой и удобно было из разных участков программы использовать доступ к таймесериям - и ? и нужно плодить 999 способов выйти из любого участка программы и не потерять предыдущие расчеты? - да это возможно, но это требует четкого плана (алгоритма) по которому будет написан исходный код... а если исходник дорабатывается путем дополнения готовых функций (классов)? - т.е. нужно будет каждый раз разбираться что там внутри... трудоемкая в общем задача для больших проектов все предусмотреть, имхо
Если работа программы устроена по клику мышкой, то тут не важно - есть доступ, или его ещё нету - нужно среагировать. Можно много писать как всё плохо сделали, но лучше в данном случае - иметь свой кэш, из которого всегда есть доступ по требованию.
Только представь себе программу, которая вместо того, чтобы выдать что-то на давно просчитанных исторических данных по клику мышой, говорит - сходи покури - я пока текущие данные получаю, которые тебе не нужны сейчас, и перестраиваю таймсерию...
Что ни говори, а если нужно сделать из того, что имеем, то лучше выдать то, что есть в кэше, а потом уже перестраивать его после разблокировки доступа к таймсерии.