ArrayCopyRates()
Хорошо бы иметь возможность определять не только сам процесс подгрузки, но и состояние данных - полностью подгружены или нет.
Автомасштабирование.
Autoscale must die! Пожалуй именно эта фраза охарактеризует истинное отношение всей мировой здравомыслящей общественности к такому явлению как автомасштабирование.
Фактически, если присутствовало сильное ценовое движение, то достаточно прокрутить график на несколько баров и он меняется просто до неузнаваемости!
Это определённо собьёт с толку любого, а особенно тех, кто работает, используя визуальные паттерны.
Самое неприятное, что исправить это невозможно.
В самом терминале, правда, присутствуют опции изменения масштаба и пр., но то, как это работает обескураживает: справа на чарте появляется какая то дубина изменяемой длины, которая упирается в границы экрана, и многие, думаю, замечали, что если амплиттуда высока, свечи просто не влазют в окно, скроллинг упирается в какую-то невидимую преграду!
Что это за преграда такая?
Это плохой алгоритм. Дело в том, что как и многие, я на заре своего знакомства с Паскалем и Дэлфой тоже пыталси творить и первым моим алгоритмом был тот, что мы видим в Метатрейдере. Он меня тогда совершенно не устроил и результатом стала реализация, описанная ниже.
Интерфейс выглядел как 4 опции в фиксируемых кнопках:
- привязка серии к верхней границе окна
- привязка серии к нижней границе окна
- масштабирование по центру среднего от экстремальных видимых значений без масштабирования
- то же, с масштабированием.
То есть из этих четырёх строчек видно, что при масштабировании графика используются 3 значения: максимальное видимое, минимальное видимое и их среднее на центре экрана как уровень отсчёта. Они позволяют реализовать любую привязку графика, удобную для пользователя. Специально можно добавить в интерфейс батон для автомасштабирования к границам экрана, который автомасштабирование полностью заменит.
Не вижу случаев надобности в autoscale ни процессе осуществления ТА ни в торговом процессе, кроме как для демонстрации мнимого быстродействия проги новоявленному ламеру типо меня на фоне мышечного скроллинга (тоже, кстати, не нужен). :)))) А вред от дизориентации - очевиден. :)
Наличие же дубины в правой стороне экрана мне напоминает мою первую попытку масштабирования графика в неком диапазоне, хотя нужно это делать относительно СРЕДНЕГО экстремальных видимых на графике значений. Тогда можно крутить график вверх вниз сколько хотите и центровать специально обученной кнопкой или автоматически. А масштабировать автоматически - это конечно должно присутствовать, но никак не по умолчанию.
Autoscale must die! Пожалуй именно эта фраза охарактеризует истинное отношение всей мировой здравомыслящей общественности к такому явлению как автомасштабирование.
Фактически, если присутствовало сильное ценовое движение, то достаточно прокрутить график на несколько баров и он меняется просто до неузнаваемости!
Это определённо собьёт с толку любого, а особенно тех, кто работает, используя визуальные паттерны.
Самое неприятное, что исправить это невозможно.
В самом терминале, правда, присутствуют опции изменения масштаба и пр., но то, как это работает обескураживает: справа на чарте появляется какая то дубина изменяемой длины, которая упирается в границы экрана, и многие, думаю, замечали, что если амплиттуда высока, свечи просто не влазют в окно, скроллинг упирается в какую-то невидимую преграду!
Что это за преграда такая?
Это плохой алгоритм. Дело в том, что как и многие, я на заре своего знакомства с Паскалем и Дэлфой тоже пыталси творить и первым моим алгоритмом был тот, что мы видим в Метатрейдере. Он меня тогда совершенно не устроил и результатом стала реализация, описанная ниже.
Интерфейс выглядел как 4 опции в фиксируемых кнопках:
- привязка серии к верхней границе окна
- привязка серии к нижней границе окна
- масштабирование по центру среднего от экстремальных видимых значений без масштабирования
- то же, с масштабированием.
То есть из этих четырёх строчек видно, что при масштабировании графика используются 3 значения: максимальное видимое, минимальное видимое и их среднее на центре экрана как уровень отсчёта. Они позволяют реализовать любую привязку графика, удобную для пользователя. Специально можно добавить в интерфейс батон для автомасштабирования к границам экрана, который автомасштабирование полностью заменит.
Не вижу случаев надобности в autoscale ни процессе осуществления ТА ни в торговом процессе, кроме как для демонстрации мнимого быстродействия проги новоявленному ламеру типо меня на фоне мышечного скроллинга (тоже, кстати, не нужен). :)))) А вред от дизориентации - очевиден. :)
Наличие же дубины в правой стороне экрана мне напоминает мою первую попытку масштабирования графика в неком диапазоне, хотя нужно это делать относительно СРЕДНЕГО экстремальных видимых на графике значений. Тогда можно крутить график вверх вниз сколько хотите и центровать специально обученной кнопкой или автоматически. А масштабировать автоматически - это конечно должно присутствовать, но никак не по умолчанию.
.AG писал (а):
Автомасштабирование.
Autoscale must die! Пожалуй именно эта фраза охарактеризует истинное отношение всей мировой здравомыслящей общественности к такому явлению как автомасштабирование.
Фактически, если присутствовало сильное ценовое движение, то достаточно прокрутить график на несколько баров и он меняется просто до неузнаваемости!
Это определённо собьёт с толку любого, а особенно тех, кто работает, используя визуальные паттерны.
Самое неприятное, что исправить это невозможно.
В самом терминале, правда, присутствуют опции изменения масштаба и пр., но то, как это работает обескураживает: справа на чарте появляется какая то дубина изменяемой длины, которая упирается в границы экрана, и многие, думаю, замечали, что если амплиттуда высока, свечи просто не влазют в окно, скроллинг упирается в какую-то невидимую преграду!
Что это за преграда такая?
Это плохой алгоритм. Дело в том, что как и многие, я на заре своего знакомства с Паскалем и Дэлфой тоже пыталси творить и первым моим алгоритмом был тот, что мы видим в Метатрейдере. Он меня тогда совершенно не устроил и результатом стала реализация, описанная ниже.
Интерфейс выглядел как 4 опции в фиксируемых кнопках:
- привязка серии к верхней границе окна
- привязка серии к нижней границе окна
- масштабирование по центру среднего от экстремальных видимых значений без масштабирования
- то же, с масштабированием.
То есть из этих четырёх строчек видно, что при масштабировании графика используются 3 значения: максимальное видимое, минимальное видимое и их среднее на центре экрана как уровень отсчёта. Они позволяют реализовать любую привязку графика, удобную для пользователя. Специально можно добавить в интерфейс батон для автомасштабирования к границам экрана, который автомасштабирование полностью заменит.
Не вижу случаев надобности в autoscale ни процессе осуществления ТА ни в торговом процессе, кроме как для демонстрации мнимого быстродействия проги новоявленному ламеру типо меня на фоне мышечного скроллинга (тоже, кстати, не нужен). :)))) А вред от дизориентации - очевиден. :)
Наличие же дубины в правой стороне экрана мне напоминает мою первую попытку масштабирования графика в неком диапазоне, хотя нужно это делать относительно СРЕДНЕГО экстремальных видимых на графике значений. Тогда можно крутить график вверх вниз сколько хотите и центровать специально обученной кнопкой или автоматически. А масштабировать автоматически - это конечно должно присутствовать, но никак не по умолчанию.
Автомасштабирование.
Autoscale must die! Пожалуй именно эта фраза охарактеризует истинное отношение всей мировой здравомыслящей общественности к такому явлению как автомасштабирование.
Фактически, если присутствовало сильное ценовое движение, то достаточно прокрутить график на несколько баров и он меняется просто до неузнаваемости!
Это определённо собьёт с толку любого, а особенно тех, кто работает, используя визуальные паттерны.
Самое неприятное, что исправить это невозможно.
В самом терминале, правда, присутствуют опции изменения масштаба и пр., но то, как это работает обескураживает: справа на чарте появляется какая то дубина изменяемой длины, которая упирается в границы экрана, и многие, думаю, замечали, что если амплиттуда высока, свечи просто не влазют в окно, скроллинг упирается в какую-то невидимую преграду!
Что это за преграда такая?
Это плохой алгоритм. Дело в том, что как и многие, я на заре своего знакомства с Паскалем и Дэлфой тоже пыталси творить и первым моим алгоритмом был тот, что мы видим в Метатрейдере. Он меня тогда совершенно не устроил и результатом стала реализация, описанная ниже.
Интерфейс выглядел как 4 опции в фиксируемых кнопках:
- привязка серии к верхней границе окна
- привязка серии к нижней границе окна
- масштабирование по центру среднего от экстремальных видимых значений без масштабирования
- то же, с масштабированием.
То есть из этих четырёх строчек видно, что при масштабировании графика используются 3 значения: максимальное видимое, минимальное видимое и их среднее на центре экрана как уровень отсчёта. Они позволяют реализовать любую привязку графика, удобную для пользователя. Специально можно добавить в интерфейс батон для автомасштабирования к границам экрана, который автомасштабирование полностью заменит.
Не вижу случаев надобности в autoscale ни процессе осуществления ТА ни в торговом процессе, кроме как для демонстрации мнимого быстродействия проги новоявленному ламеру типо меня на фоне мышечного скроллинга (тоже, кстати, не нужен). :)))) А вред от дизориентации - очевиден. :)
Наличие же дубины в правой стороне экрана мне напоминает мою первую попытку масштабирования графика в неком диапазоне, хотя нужно это делать относительно СРЕДНЕГО экстремальных видимых на графике значений. Тогда можно крутить график вверх вниз сколько хотите и центровать специально обученной кнопкой или автоматически. А масштабировать автоматически - это конечно должно присутствовать, но никак не по умолчанию.
Масштабирование это бич. Согласен. Но согласны ли с этим разработчики.
PS. Мне оно то же не нравится. Просто хотелось что бы в следующей версии (не в билде) это было реализовано. Хотя ждать похоже еще долго.
.AG писал (а):
ArrayCopyRates().
Целый день возился.
Во-вторых, - глюки в работе индикаторов, особено навороченных. Вдумайтесь, подгрузка данных начинается с того, что УМЫШЛЕННО ФОРМИРУЕТСЯ ДЫРА! Вопрос: что делать индикатору, если он считает не задом наперёд, а В ПОРЯДКЕ ПОСТУПЛЕНИЯ ДАННЫХ? Индикатор не может тормозить интерфейсный поток, так получается поток тормозит индикатор? :) Подобный порядок подгрузки некоторые индикаторы просто вырубает, и в Метаквотс было достаточно обращений по этому поводу.
Посмотрите на примеры макдов, ма и пр. В недалёком прошлом они расчитывались Метаквотсом С ХВОСТА, а может и сейчас их так считают! :)
Вероятно, Вы не вдавались в детали расчетов индикаторов и делаете
теоретические выводы.ArrayCopyRates().
Целый день возился.
Во-вторых, - глюки в работе индикаторов, особено навороченных. Вдумайтесь, подгрузка данных начинается с того, что УМЫШЛЕННО ФОРМИРУЕТСЯ ДЫРА! Вопрос: что делать индикатору, если он считает не задом наперёд, а В ПОРЯДКЕ ПОСТУПЛЕНИЯ ДАННЫХ? Индикатор не может тормозить интерфейсный поток, так получается поток тормозит индикатор? :) Подобный порядок подгрузки некоторые индикаторы просто вырубает, и в Метаквотс было достаточно обращений по этому поводу.
Посмотрите на примеры макдов, ма и пр. В недалёком прошлом они расчитывались Метаквотсом С ХВОСТА, а может и сейчас их так считают! :)
Индикатор всегда может узнать объем просчитанных данных через функцию IndicatorCounted(), которая возвращает количество баров, не измененных после последнего вызова индикатора. Большинство подсчитанных баров не нуждается в пересчете. Функция используется для оптимизации вычислений. После подгрузки/перезагрузки/импорта данных эта функция вернет 0 (количество просчитанных баров), что дает возможность пересчитать весь индикатор заново. Поступление данных не нарушает работу экспертов.
Не забывайте - мы не даем из MQL4 автоматической возможности выкачивать данные на любую глубину, а лишь на 2048 (или больше на всю необходимую глубину, если не требуется подгрузка с нуля) баров. Если Вы используете чужие таймфреймы, то самостоятельно позаботьтесь об их первичной глубокой подгрузке. После чего дальнейшая подкгрузка недостающих данных будет производиться из MQL4.
Критика масштабирования вообще никуда не годится. Вместо теории,
нарисуйте простейшее окно со своим способом масштабирования,
а потом дайте тысяче пользователей проверить два варианта.
Мы сделали и проверили на практике очень удобную и эффективную систему автомасштабирования, которая отлично работает уже 7 лет. Претензий пока не было.
Мы сделали и проверили на практике очень удобную и эффективную систему автомасштабирования, которая отлично работает уже 7 лет. Претензий пока не было.
Renat:
Критика масштабирования вообще никуда не годится. Вместо теории, нарисуйте простейшее окно со своим способом масштабирования, а потом дайте тысяче пользователей проверить два варианта.
Мы (1)сделали и (2)проверили на (3)практике очень удобную и эффективную систему автомасштабирования, которая отлично работает уже 7 лет. Претензий пока не было.
Критика масштабирования вообще никуда не годится. Вместо теории, нарисуйте простейшее окно со своим способом масштабирования, а потом дайте тысяче пользователей проверить два варианта.
Мы (1)сделали и (2)проверили на (3)практике очень удобную и эффективную систему автомасштабирования, которая отлично работает уже 7 лет. Претензий пока не было.
Может претензий не было, потому что не было других вариантов. Мне оно не нравится, но у меня нет выхода. Пользуюсь тем что есть. А это не совсем верно. Если ответ будет, что никаких изменений не будет, то те кому это не нравится, будут искать выход из положения, и чаще всего это будет что-то другое. А совмещать несколько програм (это не каждому хочется). У Вашей разработки много положительных, я бы даже сказал отличных вещей, чего нет у других. Но хочется что бы было еще лучше.
По масштабированию: как-то давно уже единственный раз хотелось
наклеить на стену минутных графиков на листах формата А4 друг
за другом, но фиксированный масштаб не нашёл. В принципе и без
него нормально, но лишней бы такая фишка не была. ИМХО.
rsi:
По масштабированию: как-то давно уже единственный раз хотелось наклеить на стену минутных графиков на листах формата А4 друг за другом, но фиксированный масштаб не нашёл. В принципе и без него нормально, но лишней бы такая фишка не была. ИМХО.
Мы пробовали, а также старались сделать чтобы можно было печатать
длинные графики (об этом просили) на А4 "в одном масштабе".
Получалось корявое решение и от идеи отказались. Особенно, с
учетом одной из наших главных задач в разработке - сделать как
можно более простой и не перегруженный функционалом информационно-торговый
терминал.
По масштабированию: как-то давно уже единственный раз хотелось наклеить на стену минутных графиков на листах формата А4 друг за другом, но фиксированный масштаб не нашёл. В принципе и без него нормально, но лишней бы такая фишка не была. ИМХО.
Renat:
rsi:
По масштабированию: как-то давно уже единственный раз хотелось наклеить на стену минутных графиков на листах формата А4 друг за другом, но фиксированный масштаб не нашёл. В принципе и без него нормально, но лишней бы такая фишка не была. ИМХО.
Мы пробовали, а также старались сделать чтобы можно было печатать
длинные графики (об этом просили) на А4 "в одном масштабе".
Получалось корявое решение и от идеи отказались. Особенно, с
учетом одной из наших главных задач в разработке - сделать как
можно более простой и не перегруженный функционалом информационно-торговый
терминал.По масштабированию: как-то давно уже единственный раз хотелось наклеить на стену минутных графиков на листах формата А4 друг за другом, но фиксированный масштаб не нашёл. В принципе и без него нормально, но лишней бы такая фишка не была. ИМХО.
Может есть и другие решения. Но не мне об сейчас рассуждать. Не зная всех особенностей. Но возможности масштабирования, другого иногда очень хочется. Прогручиваешь график, и то, что было визуально быльшим оказывается маленьким и наоборот создает неправильное понимание происходящего. Да, конечно можно этого обходить, но это создает вполне определенный дискомфорт. И иногда (???) неправильное принятие решений. А это у же значительно хуже (не для вас, для меня).
Попробуйте сохранить необходимую вам историю одним файлом,
а затем уже распечатать.
А архиве сохраненный рисунок.
А архиве сохраненный рисунок.
Файлы:
8000x600.zip
43 kb
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Целый день возился.
Оказалось, что ф-ция в состоянии нормально запуститься только раз, и если по каким-то причинам данных нет, повторный вызов чреват ArrayCopyRates() function internal error. В last_error - ошибка 4053.
То есть фактически при отсутствии ЗАРАНЕЕ подгруженных данных функция имеет некоторую непредсказуемость, особенно при отсутствии связи с сервером.
Учитывая, что в описании ясно сказано, что копирования элементов не происходит, можно предположить, что ф-ция ищет данные на диске, и определив размер целевого массива, копирует необходимое кол-во элементов в память, устанавливая адрес первого элемента дескриптором формируемой серии.
Причём, ф-ция нисколько не заботится, есть дыры в истории или нет. Логгировал её выполнение, в массив копировались одноминутные данные после пропуска в несколько месяцев.
Когда же при отсутствии данных ф-ция скопировала 0 элементов в массив, встал вопрос, всё ли у неё гладко в работе с указателями.
Эта функция, являясь основной для работы с данными "чужых" таймфремов выявила даже не то, что она реализована по-страшному, это очевидно :), а то, что ПОНЯТНЫЙ КОНТРОЛЬ СТАТУСА ПОДРУЗКИ ДАННЫХ в нынешнем терминале просто не существует. В процессе теста ArrayCopyRates как офлайн, так и онлайн не удалось ни разу получить ошибку 4066 (ERR_HISTORY_WILL_UPDATED ), несмотря на то что данные отсутствовали. :)
В том виде, в котором ф сейчас, она мало эффективна, поскольку алгоритм её не оптимизирован: приходится дополнительно подгружать ненужные данные, например, при тестировании, хотя само наличие ф-ций iLowest и iHighest красноречиво говорит, КАК её структурировать параметрически.
Грубо простой пример: берём бар в начале окна на пике и копируем его составляющие мелкие бары.
Если взять PERIOD_D1 с PERIOD_M1 получается нечто нехилое в двух измерениях.
То есть это я медленно, но верно подвожу к тому что копировать массив пользователю нужно ОТ ТРЕБУЕМОЙ ДАТЫ, а не "с конца".
Собственно, один стратегический просчёт рождает другой.
В МетаТрейдере, думаю, все замечали, данные обновляются С КОНЦА. Если вдуматься, то логика етава действа ущербна в принципе, это потенциально влёчет риск образования дыр. :)
Во-вторых, - глюки в работе индикаторов, особено навороченных. Вдумайтесь, подгрузка данных начинается с того, что УМЫШЛЕННО ФОРМИРУЕТСЯ ДЫРА! Вопрос: что делать индикатору, если он считает не задом наперёд, а В ПОРЯДКЕ ПОСТУПЛЕНИЯ ДАННЫХ? Индикатор не может тормозить интерфейсный поток, так получается поток тормозит индикатор? :) Подобный порядок подгрузки некоторые индикаторы просто вырубает, и в Метаквотс было достаточно обращений по этому поводу.
Посмотрите на примеры макдов, ма и пр. В недалёком прошлом они расчитывались Метаквотсом С ХВОСТА, а может и сейчас их так считают! :)
Формула этих индикаторов позволяет это делать, результат тот же, но ДЕЛО - В ПРИНЦИПЕ!
Этот принцип переносится на сопутствующие моменты реализации, и вот мы уже получаем трудноустранимую погрешность в логике.
Которые и материализуются какими-то непонятными трудностями в контроле подгрузки исторических данных. То есть у меня лично трудностей нет, могу подождать, а как себя должен вести тот же скрипт, если у него нет данных, нет ошибок и ноль элементов "успешного копирования" в базе? :)