Я вообще tag никогда не использую. Время пройдет и потом пойди разберись что ты в этот tag засунул.

безосновательное заявление.


если для тебя программирование - это набор ненужных действий, то это не для тебя.


по себе о всех не судят ;)


всмысле таскать за собой? ты про что? или ты все компоненты на форме в рантайме создаешь???

Ну почему? Разобраться можно, если, конечно, в OnCreate глянуть...

Добавлено через 3 минуты и 14 секунд
Просто оставить комментарий - "что такое Tag смотри в OnCreate"   
А можно прямо там и подробный комментарий написать, что, мол, в Tag'ах хранятся порядковые номера элементов
перечеслимого типа...

Ну и опять таки получается больше телодвижений  
Так что на мой взгляд - это плохой вариант, неоптимальный.

и:

Вот смотри ситуацию:
Я в моем проекте сначала реализовал работу приложения с XML-файлом, в качестве хранения настроек к приложению. Руководитель,
сказал немудрить ребята ручками все сделают. Но при этом объектов автоматизации где применяется моя прога, очень много!
Правка в ручную XML-файла занимает не менее 20 или 30 мин.
Че я сделал? Мне стало влом править файл и я добавил опрос COM-сервера, он выдал все что у него есть, я проставил напротив того чего мне надо галочки и нажал "Применить". Операция работы с XML-файлом стала занимать не больше 3 мин.

Скажи мне теперь, что лень это плохо и не выгодно? ;)



Когда правится свойство компонента в дизайн-тайме, куда все ложится и хранится? Не в файл ли dfm ? Ну так вот, к примеру человек
писал для delphi 5, ну есть у него лицензионная копия потому и пишет, а его товарища к примеру другая дельфи и у которой формат dfm немного отличается. Что тогда? Тогда я его товарищу, не обходимо глянуть что и как там лежит, а для этого разобраться - а это иногда больше чем 10 мин. и поправить иногда 5 мин. и того 15 мин. в пустую убить. А ведь за 15 мин. можно под отладчиком и баги новые отладить!!! или чаю попить!

ЗЫ:
Мое мнение, а от него и такие ответы на форуме. Программист это не тот кто пишет код, а тот думает о последствиях кода! Т.е. сопровождении и ряда других последствиях.

ну-ну! Автомоблист - это не то, кто ездит на автомобиле, а тот, кто думает, что может попасть в аварию при езде на автомобиле...
а св-во tag у компонента AFAIK чуть ли не с первых версий делфи есть и деваться никуда не собирается.
и используется оно для хранения связанных с компонентом данных.

MetalFan, не будем офтопить ))) Я тута по делу,т.е. по теме ))
Ради интересу обрисовал данный вопрос своему другу Sega-Zero\Завсегдатай_Delphikingom.ru он посоветовал юзать RTTI, т.к. говорит там никакой динамикой не пахнет и все эти возврат имени класса и т.д. являются статической дурью.

Вот цитата из лога переписки с ним:

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

  Полностью согласен. Зачем использовать тут строки? Зачем тут RTTI??? Это уже усложнение, а не упрощение.

aktuba, ты мой пост полностью прочеЛ? ))) там написано, что вариант не мой!!!
А второй:


В чем конечно я частично соглашаюсь 

ЗЫ:
Учимся внимательно читать посты!

ЗЫ2:
Специалист обязан знать тонкости специфики и чем больше тем лучше

Да прочел я. Но в корне не согласен с тем, что написано:



Такие ограничения в данной задаче - все равно, что за хлебом дорогу перейти = слетать на самолете. Для чего? Бред какой-то...



Если это называется красивый код - то я вообще не разбираюсь в красоте кода. Надо было по всей форме рекурсивно пробежаться   



Для меня не только не быстрее, но и не красивее, не удобнее, не... Дальше продолжи сам.



А это тут при чем? Есть опыт работы с RTTI и что? Теперь на каждом шагу применять? Таким подходом - лучше тогда отбросить ООП, Delphi и т.д. и сесть за маш.коды - вот где красота и скорость будет. В Delphi всегда главным преимуществом было четкость, легкая читаемость кода. Не надо для перевозки ящика пива железнодорожный состав нанимать!!! Хватит и попутку поймать.


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

Ребята! Вы ушли глубоко в   

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

Я уже 13 постов назад выбрал для себя оптимальный вариант. 

Остановитесь или пишете друг другу личные сообщения - к чему тут то разводидить беседу.
Я б еще понял, если бы предлагались варианты оптимальнее, но вы ж уже такое нагородили....  
Усложнили задачу по самые небалуй  

P.s.: Не ожидал такой активности в теме. Я понимаю, если б обсуждалось как организовать оптимальный генетический алгоритм
составления какого-нибудь расписания. Тут то задачка... так... чисто для красоты кода, т.к. скорость здесь не имеет никакого значения!

Это сообщение отредактировал(а) ALeXandrK - 20.8.2007, 02:12

Вот и я про то же   

Советую использоват не семь TCheckBox а один TCheckListBox из закладки Additional.

Код

type   TEnumWD = (wdMo=1, wdTu=2, wdWe=3, wdTh=4, wdFr=5, wdSa=6, wdSu=7);   TWeekDays = set of TEnumWD; var   StudingDays: TWeekDays;    procedure TForm1.CheckListBox1Click(Sender: TObject); var i: Byte;     P: Byte; begin     StudingDays:= []; // Так как посоветовал EvilsInterrupt     for i:= 1 to 7 do      begin         P:= Ord(CheckListBox1.Checked[i-1])*i;  // Так как ты хотел         Include( StudingDays, TEnumWD( P ) );     end; end;

Это сообщение отредактировал(а) Gwire - 23.8.2007, 13:05

Неплохая мысль. Про существование TCheckListBox я и забыл