Ошибки, баги, вопросы - страница 679
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Опять двадцать пять.
На форуме нашёл множество вопросов-ответов по ошибке 4802 в разных ветках. Всё у себя проверил (пути на диске и в своём коде в iCustom), кастомный индикатор скомпилировал, основной тоже - в итоге ошибка в терминале: "2012.03.24 16:44:31 11 (NZDUSD,H4) cannot load custom indicator 'C:\Program Files\MetaTrader 5\MQL5\Indicators\Examples\iCFractals.mq5' [4802]".
iCFractals.mq5 - копия стандартного Fractals.mq5, основной индикатор - копия iFractals из справки с заменой:
на вышеприведённый код.
Билд 619 x32.
А Вы точно все сделали как написано в справке? https://www.mql5.com/ru/docs/indicators/icustom Там же еще и пример есть ниже.
А Вы точно все сделали как написано в справке? https://www.mql5.com/ru/docs/indicators/icustom Там же еще и пример есть ниже.
Сделал всё. Даже на всякий случай ущипнул себя. Безрезультатно.
Затем проделал ещё раз то, на что особой надежды не было, поскольку в прошлый раз не помогло: убрал расширение из имени индикатора. Теперь всё сработало.
Спасибо!
Какими стихийными бедствиями обернётся для терминала введение для каждого бара (кроме M1-таймфрейма) такого дополнительного параметра, как точное (M1) время high- & low-экстремумов? Пока все точные значения времени баров старших таймфреймов приходится ресурсоёмко вычислять самому средствами MQL. Лично мне очень не хватает доступа к готовым точным значениям. Ведь если история качается в минутках, а прочие таймфреймы формируются локально из M1, то во время их предварительной отстройки терминал мог бы просто заодно рассчитывать точные значения и складывать в БД, которая чуть вырастет. У меня вообще неготовность точных времён для баров тащит за собой целый ворох проблем, таких, например, как собственно необходимость заморачиваться на сей счёт самому, принципиальная невозможность ограничить количество баров в окне терминала, ибо уточняющие расчёты бьют глубоко в историю, которую нельзя ограничивать, и как следствие перерасход памяти, не говоря уже о длительности самих расчётов... На вторичную проблема никак не тянет.
В принципе затраты памяти выростут не особо сильно, тк не нужно хранить datetime high & low, а всего лишь разницу с открытием бара.
Но я думаю что для многих интересующихся важнее не точное время high & low, а кто из них был раньше. Ведь не всегда же у бычьей свечи первым наступает low, бывает наоборот, хотя конечно реже. Но раз уж заявлено что моделирование точное, то думаю не будет вредно закодировать кто был раньше.
А это по затратам памяти вообще мизер ( 1 дополнительный бит).
Urain:
Но раз уж заявлено что моделирование точное, то думаю не будет вредно закодировать кто был раньше.
Моделирование точное и строится на основе информации из минуток.
Если же кто-то на Daily хочет узнать некие отрывочные данные из предыдущей истории, то нужно именно брать и анализировать эту историю (минутную). Придумывать варианты "экстремум хай-лоу и тд" не надо - это именно частные случаи.
Моделирование точное и строится на основе информации из минуток.
Если же кто-то на Daily хочет узнать некие отрывочные данные из предыдущей истории, то нужно именно брать и анализировать эту историю (минутную). Придумывать варианты "экстремум хай-лоу и тд" не надо - это именно частные случаи.
Моделирование точное и строится на основе информации из минуток.
Если же кто-то на Daily хочет узнать некие отрывочные данные из предыдущей истории, то нужно именно брать и анализировать эту историю (минутную). Придумывать варианты "экстремум хай-лоу и тд" не надо - это именно частные случаи.
Ренат, вашу минутную историю необычайно трудоёмко анализировать. Такой анализ чреват множеством "красивых глюков" [(с) MetaQuotes Software Corp.]. И вы знаете почему - из-за пропущеных баров.
--
Если хотите сделать передовой терминал, нужно систематически внедрять передовые возможности в терминале. Делать то, чего нет ни у кого из конкурентов. Т.е. отходить от традиций в пользу большей информативности, скорострельности, системности (взаимосвязности), экономности и прочей юзабельности. Даже если данные конкретные возможности/сервисы большинством невостребованы. Вы регулярно делаете одну и ту же стратегическую ошибку - ориентируесь при принятии решений на статистичекие размеры групп потребителей конкретного сервиса.
Сделать продукт удобный (= кагбе привлекательный?) для статистического большинства юзеров и предполагать что это большинство автоматически начнёт массово потреблять продукт - утопическая политика. Стадо имеет иерархическую структуру и всегда движется вслед за лидерами подрупп. Пока это не станет аксиомой вашей юзабилити-стратегии, вы будете продолжать совершать грубые просчёты в оценке потенциальной привлекательности ваших сервисов.
В контексте вышесказанного есть грандиозные ресурсы повышения привлекательности терминала для масс - например, реализовать наконец "бездырочную" минутную историю, таки возможность тестировать на сторонних котировках, ОСО ордера, и множество других "статистически невостребованных" сервисов, представляющих реальный (не высосанный из пальца) интерес для интеллектуальных лидеров ваших же форумов.
Ренат, вашу минутную историю необычайно трудоёмко анализировать. Такой анализ чреват множеством "красивых глюков" [(с) MetaQuotes Software Corp.]. И вы знаете почему - из-за пропущеных баров.
Это дело программиста анализировать данные. Выше приведенный запрос был исключительно частным и не имеющим никакого отношения к нам или терминалу.
Вопросы про пропущенные бары от незнания рыночной ситуации. Загляните для расширения кругозора на чарты акций или фьючерсов и вопросы про "дыр быть не должно" мгновенно отпадут.
Если хотите сделать передовой терминал, нужно систематически внедрять передовые возможности в терминале. Делать то, чего нет ни у кого из конкурентов. Т.е. отходить от традиций в пользу большей информативности, скорострельности, системности (взаимосвязности), экономности и прочей юзабельности. Даже если данные конкретные возможности/сервисы большинством невостребованы. Вы регулярно делаете одну и ту же стратегическую ошибку - ориентируесь при принятии решений на статистичекие размеры групп потребителей конкретного сервиса.
Это общие слова. Тем более про стратегию.