Ошибки, баги, вопросы - страница 519
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Приведите пример одной из многих задач, где может понадобится множественная расстановка приоритетов.
Перечислять примеры особого смысла нет - ведь сейчас их может быть немного, но многие задачи возникнут по ходу разработки того или иного кода в будущем и будут накапливаться как проблема и как очередной пример. Не попросишь сейчас реализовать - через полгода всё равно приспичит.
Пока в этом ключе назревает всего одна, но конкретная проблема: после программного построения вразброд линий невозможно прямо с графика, без вызова окошка "Список объектов", с комфортом удалять вручную те или иные наложенные друг на друга графические объекты в логическом порядке убывания важности (важность напрямую завязана на относительную степень старшинства каждого из таймфремов). Хотелось бы так: при любых обстоятельствах программно (за счёт установки свойства визуального приоритета в нужное значение) объекты от разных ТФ выстраивались бы среди себе подобных (т. е. не обязательно с наложением, а так же и втискиванием между) в порядке нарастания важности, чтобы самый верхний был бы самым важным, а при ручной разборке в обратном порядке можно было бы добираться по порядку до менее важных. И всё это делалось бы по науке, с программным выставлением очерёдной последовательной градации через свойство, а не ухищрениями типа кого позже создал, тот и сверху (ведь в задачах графической разметки бывает множество случаев, когда объекты от разных ТФ порождаются не в строгой прямой последовательности, а через пень колоду), что и порождает беспорядок в визуальном первенстве. И даже OBJPROP_ZORDER тут не поможет, ибо программное задание порядка доступа к объекту обеспечит лишь приоритет выделения мышкой, но нужный объект зачастую всё равно будет перегорожен самым верхним, а хочется сразу "что делаю, то и вижу", без углубления в подокна типа "Свойства объекта" и т. д.. Ведь тем приятнее работать с графическим интерфейсом, чем он нагляднее и чем меньше телодвижений необходимо совершить, чтобы что-то про что-то выяснить или осуществить с этим конечную - целевую - манипуляцию.
А почему нельзя сравнить объекты? Ведь у линий на разных ТФ есть конкретная цена. Вот и сравнивайте цену. Если цены равны, то рисуйте наиболее важную (на Ваш взгляд) линию. Это и будет расстановка приоритетов.
Для начала сообщаю, что, например, у такого объекта, как Вертикальная линия, цены нет. Есть только время. Но если время у обоих линий одно и то же, а они были выставлены от разных ТФ, то последней могла выстроиться линия от младшего ТФ, что визуально перекроет линию от старшего. Конечно, есть возможность именовать объекты (например, добавляя имя таймфрейма в конец имени объекта), а потом сравнивать, но это может помочь разве что в задаче поиска уже наклёпанных объектов, а не в очерёдности их первичной расстановки.
В общем, пока ничего не предусмотрено для того, чтобы просто и красиво задавать приоритет видимости по желанию пользователя, а не велению объективных обстоятельств на рынке, да ещё при одновременном прослушивании "случайного" рынка на разных ТФ.
А время сравнить не получается?
Потому и не подходит, что это свойство относится к аспекту выделения графического объекта мышкой, а не к порядку визуализирования оного.
Тогда предлагаю написать в СД заявку, потому что имхо порядок выделения должен совпадать с порядком визуализации - иначе получается совершенно неинтуитивно. Выделяться должно то, что на "поверхности". zorder по идее и существует для того, чтобы объекты могли "отвязать" свой приоритет от очередности создания.
У Вас, как я понял, проблема в том, что одна линия закрывает другую. Вам нужен приоретет, для того, чтобы выделять значимую (для Вас) линию на передний план. Если времена у всех линий разные, то приоретет не важен, так как линии не перекрываются. Вас интересуют времена, при которых линии перекрываются. Вот Вам и точка одсчета - время линий, когда время одинаково. Или я не правильно понял Вашу проблему?
Ещё раз: с выделяемостью всё хорошо, приоритет можно выставить. С приоритетом визуализации всё плохо. И "порядок выделения должен совпадать с порядком визуализации" - сомнительный вывод. Порядок чего угодно никому ничего сам по себе не должен. Должна быть возможность на усмотрение пользователя задавать любой приоритет объектам, требующим задания оного для удобства восприятия/доступа/манипулирования/etc. Может, найдётся чудак, который живёт на антресоли и спит в ластах свесившись вниз головой - ему очевидный порядок не подойдёт, но и для этого чудака должна существовать возможность по своему усмотрению задавать тот приоритет объектам, какой ему кажется наиболее логичным.
Нафиг "еще раз"? Самому не понятно? Я предложил рабочий вариант, единственно логичный: zorder меняет и порядок выделения и видимости, поскольку выделять то, что невидно в нормальных условиях никому в голову не прийдет. Если это не очевидно - флаг вам в руки - пытайтесь продвинуть "веса", "приоритеты" и прочие отсутствующие свойства.
Я предложил рабочий вариант, единственно логичный: zorder меняет и порядок выделения и видимости, поскольку выделять то, что невидно в нормальных условиях никому в голову не прийдет.
Закешированные индикаторы принципиально не желают пересчитываться при изменении внешнего параметра.
Пример запускаю индикатор с параметром А, получаю данные, изменяю параметр с А на Б, данные не меняются, удаляю индикатор.
Запускаю индикатор сразу с параметром Б, данные те же что и с параметром А.
Удаляю индикатор, закрываю терминал, жду пока процесс убъётся.
Открываю терминал, запускаю индикатор сразу с параметром Б.
Получаю (правильный расчёт для параметра Б) совершенно другие данные.