ArrayCopyRates() - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Попробуйте сохранить необходимую вам историю одним файлом, а затем уже распечатать.
А архиве сохраненный рисунок.
Рош, вопрос был не в этом. Мне не нужна копия экрана (графика для ручного анлиза), может просто до этого еще недорос. Но визуально график обманывает. И только своим масштабированием. Я не собирался начинать эту тему, но она была поднята. И я постарался высказать свои мысли. И хочу просто что бы в следующей версии эта проблема была решена. Может и не так удачно, как хотелось. Но каждый из нас имеет право выбирать для работы тот масштаб, который его устраивает. Хотя по большому счету можно это и сейчас. Ставишь фиксированный масштаб, но тогда не заглядывй в историю. А хочется это правило масштабирования перенести на всю доступную историю.
и М1 с таким же масштабом:
Все это показывает стандартную проблему "решение одной проблемы порождает еще бОльшую проблему". Поэтому наше решение гораздо лучше.
Масштабирование на всей истории делается легко. Например, EURUSD с мин 0.80, макс 1.45:
и М1 с таким же масштабом:
Все это показывает стандартную проблему "решение одной проблемы порождает еще бОльшую проблему". Поэтому наше решение гораздо лучше.
Так я как раз о том и писал, что если "первичная глубокая" подгрузка отсутствует, то результаты у скрипта НЕПРЕДСКАЗУЕМЫ. Не мне вам объяснять, что такое непредсказуемость кода. :)
Другое дело, если прикинуть, сколько минутных баров в сутках, то получается, если юзер ежедневно не пользуется терминалом, эта "первичная глубокая подгрузка" становится просто его "бичом божием", веть эксперт не определяет наличие этой "глубины", он просто начинает считать, уповая на ошибку 4066.
Но она не возникает! Поэтому проиходится возникать юзеру.
Я писал выше, но видимо это ускользнуло от вашего внимания: возможны ситуации, когда первичная глубокая подгрузка не нужна в принципе, например, если пользователю, требуется только "наполнение" пикового дэйского бара значениями др. таймфреймов, а пиковый бар вполне может быть где-то в середине окна .
Возможно я несколько непонятно высказался... О существовании чекбокса "Фиксированный масштаб" нам, разумеется, известно.
Я имел ввиду ЛОГИКУ масштабирования.
В случае МТ если отключить autoscale, то бары будут строиться в диапазоне цен! И если диапазон достаточно широк, то градации масштабирования естественно может не хватит, но переместить лапой график НЕВОЗМОЖНО, он упирается в установленные ограничения!
То есть алгоритм скорее всего таков:
- горизонтальный масштаб не изменяется,
- вычисляются максимальное и минимальное ценовое значение на графике (диапазон цен баров в окне),
- расчитывается вертикальный масштаб, чтобы вогнать серию в окно.
Так называемый фиксированный масштаб - это просто отключение последней операции.
То есть логика вашей реализации масштабирования - показать весь диапазон баров в окне.
Это удобно при презентации роста показателей трудового коллектива, но при трейдинге- не очень. :)
Логика формирования ценовых данных и должна определять логику масштабирования (а также логику подгрузки данных и все другие логические логики).
ВСЯ БОТВА - ВОКРУГ ПОСЛЕДНЕГО БАРА! В нашем случае его положения в окне. В некоторых программах его автоматически удерживают на середине по вертикали, при восходящем тренде можно привязывать максимум серии к верхней границе окна +несколько пикселей отступа, при нисходящем зеркально. Это визуально обеспечит удобную видимость последней свечки на фоне формируемой тенденции и график скроллится без скачков масштабирования. Это только пример. Здесь вопрос, скорее всего, - в отправном уровне, с которого вы начинаете расчитывать построение баров в пикселях. Вероятно, он у вас на верхней границе окна.
Я понимаю, что любая критика "никуда не годится" и не может нравится. Особенно профессионалам.:)
Поэтому любители и молчат, чтобы не демонстрировать глубину своего "ламерства" уже 7 лет.
Многие просто не представляют, КАК может быть по-другому. :)
Таракан вашей реализации фм - здесь. :)
integer,
жать бар по вертикали до беконечности нет смысла, он должен иметь НЕОБХОДИМУЮ для удобного восприятия высоту.
Здесь речь идёт о ситуации, когда при включенном фиксированном масштабе и сильном тренде
свечи упираются в границы экрана и нет никакой возможности их передвинуть в желаемом направлении, как-будто при расчёте использовались бары за пределами окна.
По ArrayCopyRates:
Так я как раз о том и писал, что если "первичная глубокая" подгрузка отсутствует, то результаты у скрипта НЕПРЕДСКАЗУЕМЫ. Не мне вам объяснять, что такое непредсказуемость кода. :)
Другое дело, если прикинуть, сколько минутных баров в сутках, то получается, если юзер ежедневно не пользуется терминалом, эта "первичная глубокая подгрузка" становится просто его "бичом божием", веть эксперт не определяет наличие этой "глубины", он просто начинает считать, уповая на ошибку 4066.
Но она не возникает! Поэтому проиходится возникать юзеру.
Я писал выше, но видимо это ускользнуло от вашего внимания: возможны ситуации, когда первичная глубокая подгрузка не нужна в принципе, например, если пользователю, требуется только "наполнение" пикового дэйского бара значениями др. таймфреймов, а пиковый бар вполне может быть где-то в середине окна .
Если запрашиваемый символ присутствует в окне рынка, то никакой ошибки при повторном запросе ArrayCopyRates не будет.
А проверять, что же получил на самом деле в любом случае надо. Сначала проверить наличие ошибки 4066, а потом в цикле с некоторой задержкой проверить время нулевого бара.
Ф-ция IndicatorCounted() относится к так называемым избыточным функциям.
Избыточные ф-ции разрабатываются специально для ламеров и характеризуются скрытыми расчётами с неясным возвратом.
При наличии качественно реализованного контроля подгрузки данных для пользователя обе эти ф-ции были бы в принципе не нужны, хотя и сейчас можно без них обойтись, но уже "на свой страх и риск".
Логика ф-ции IndicatorCounted() ущербна по замыслу её создателя. Это связано с её совершенством, ибо в совершенстве нет предела, как и в истории.
К сожалению, большинству пользователей абсолютно всё равно, что там было "каунтин", но "анкаунтин" волнуит и тревожит.
Их интересует смещение бара, где они остановились, но ф-ция IndicatorCounted говорит на языке недомолвок и иносказаний, поэтому несколько тысяч пиплов, её юзающих, восхищённые и удивлённые огромным количеством подсчитанных ею в прошлой пятилетке баров, вынуждены потом дружно производить вычитания с Барсом и декрементом калкуляртырами своих кампутиров, дабы процесс впечатлял.
Так что будем ожидать в следующем десятилетии функцию IndicatorCounted_Until(), которая вернёт шифт всем страждущим МТ5 и ждущим перемен 7 долгих лет. :)