Как правильно удалять объекты на графике - страница 5

 
keekkenen >>:

а что будет, если пользователь удалит глобальную переменную ?

идентификатор индикатора нужен самому индикатору, так зачем его выносить в глобальную переменную,

все-равно пользователь вешает индикаторы ?

к тому же функция GetID() соврет для очередной копии индикатора, использующего ваш подход после того, когда пользователь повесит какой-нибудь левый индикатор (например, из стандартного набора), затем использующий ваш подход ..

Да. Согласен. Мне, например, подход с рандомом, как у gip'а понравился. Возможно, в ф-ии GetID заменю GV на рандом. Но речь-то ведь не об этом. Проти этого я как раз не против. Оба подхода имеют право на существование.

 
Integer >>:

Петр, ваш подход тоже не подойдет, если в одно подокно нужно накидать несколько индикаторов рисующих объекты.

Почему? Давайте разберем. что произойдет. Предположим, кидаем в первый раз (ID=1). Кидаем второй индикатор - его ID будет равным 2. Соответсвенно, имена объектов будут уникальны. Они ведь не к номеру подокна привязаны, а к ID индикатора, который каждый раз уникален. Так что все проходит. Покажите мне ситуацию, когда моя библиотечка бы не справилась.

Когда стояла такая задача делал просто - в окне свойств переменная SubWinName - имя подокна (оно устанавливается как IndicatorShortName() в init), и переменная ObjectID, все остальное (какие значения установить в SubWinName и в ObjectID) - проблемы пользователя. По большому счету - нет абсолютно правильного метода и абсолютно надежного метода получения ID для объектов. MathRound() - нет гарантии, что не будет двух одинаковых случайных чисел. GetTickCount() - тоже не факт, что не будет одинаковых значений. Счетчик на глобальных переменных - при аварийном завершении работы терминала не произойдет сброса (хотя это не помешает правильной работе при следующем запуске терминала, просто счетчик будет сдвинут. Вообще это метод с наибольшими гарантиями.

С этим согласен. Абсолютной гарантии дать невозможно.

 

Еще по избыточности.

Ф-ии Clear() и DelObjects(). Если в первом случае приходится перебирать ВСЕ существующие на инструменте объекты (а их может быть на порядки больше чем те, что нужно удалить), то во втором - перебор с удалением идет только по тем, что созданы индикатором, по тем, что подлежат удалению. Так что избыточность - это для первого случая. Потом, сама строковая операция с поиском строки - медленная. Это, конечно, все фигня - но все же, если у разговор зашел про избыточность.

 
gip >>:

Функцию Свинозавра я бы подкорректировал следующим образом:


.Ёпрст. Сбили вы меня этими уникальностями. Можно ещё проще:

IndicatorShortName("123");
int win=WindowFind("123");
IndicatorShortName(ShortName);
 
gip >>:


.Ёпрст. Сбили вы меня этими уникальностями. Можно ещё проще:


Да. Достаточно из обращающегося индюка обратиться. Согласен. ))) В остальных-то индюках в эо время свои родные кор. имена.

Тут я точно избыточен!!! Спасибо.

 
keekkenen >>:

может проще использовать в качестве постфикса в именованиях объектов имя индикатора и локальное время, когда он был инициализирован, для ручного цепляния этого должно быть достаточно, но для шаблонного не сгодится..

Не проходит. Терминал, время от времени, приходится иногда перезапускать. Тогда привязка ко времени... увы.

Кстати, я так и делал в начале, когда пытался решить свою проблему. Можно даже поискать - где-то код лежит на форуме. Но не прокатило.

 
Svinozavr писал(а) >>

Почему? Давайте разберем. что произойдет. Предположим, кидаем в первый раз (ID=1). Кидаем второй индикатор - его ID будет равным 2. Соответсвенно, имена объектов будут уникальны. Они ведь не к номеру подокна привязаны, а к ID индикатора, который каждый раз уникален. Так что все проходит. Покажите мне ситуацию, когда моя библиотечка бы не справилась.

С этим согласен. Абсолютной гарантии дать невозможно.

Удаление справится, индикатор не справится с рисованием объектов. Второй индикатор в подокне не найдет своего подокна по своему имени.

 
Integer >>:

Удаление справится, индикатор не справится с рисованием объектов. Второй индикатор в подокне не найдет своего подокна по своему имени.

А... блин! Точно.))) Потому как имя подокна уже занято. Да... - это не прокатит.

 

Ситуация:
В окне графика советник создает граф объекты с уникальными именами.
Затем удаляет ф. ObjectDelete. Обычно все нормально проходит - объекты удаляются.
Но! Иногда бывает, что вроде бы удаленный объект остается на графике.
"Вроде бы удаленный " означает, что в списке объектов (по правой кнопке мыши) он отсутствует, а на экране остался.
Наводишь курсор, всплывает его законное имя, а в списке объектов его нет...
Как такое может быть?
И как удалять правильно?

Причина обращения: