![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Опять проблема с именами :)
Psychedelic © (2007-01-25 23:41:00)Здравствуйте.
Владимир к вам вопрос.
Наткнулся тут на такую бяку.
procedure TObj.SetName(const NewName: String);
...
if NewName <> '' then
if FindObj( NewName ) <> nil then Exit; // prevent duplications!
А зачем собственно говоря это нужно???
Мало того того что забирает лишнее время так еще и приводит к такой ситуации:
К примеру есть две формы, на каждой форме кидаем по лэйблу,
в этом случае второму лэйблу имя не будет присвоено!
т.к. у обоих имя Label1.
Вы не могли бы убрать? А то приходиться переименовывать, потом вспоминать есть ли это имя на других формах...
Да и не логично это как-то. Ведь на форме двух имен и так не будет,
IDE отслеживает ведь, или я ошибаюсь?
Vladimir Kladov (2007-01-29 17:16:00) [1]В VCL Tag (и Name) появляется для TComponent, у нас Tag есть для TObj, почему не быть там же и Name?
Psychedelic (2007-01-29 16:16:00) [2]Владимир а можно прикрепить NamedObjectList к Tobj (не в техническом смысле)? тогда проблема с TKOLDataModule будет решена.
Или это неприкасаемая основа?
Psychedelic (2007-01-29 15:17:00) [3]
> Думаю что Владимиру как раз будет меньше работы, ксли ты
> отошлеш как нужно для твоей реализации, без IFDEF.
Ну у вас и слог... :) Еле понял. - ошибка на ошибке.
Да нет, там много изменений, и они разбросаны и в KOL , и в mirror и mirror obj. Замучаешся перебирать.
Лучше как я предлагаю, - я вышлю готовые модули, но там где есть изменения будут спец знаки. Т..е они даже не откомпилятсья...
И еще проблема : что делать с именами в TKOLDataModule?
homm (2007-01-29 15:09:00) [4]Думаю что Владимиру как раз будет меньше работы, ксли ты отошлеш как нужно для твоей реализации, без IFDEF. Просто не так чтонить оформиш, потом переделывать только хуже. ИМХО.
Psychedelic (2007-01-29 14:38:00) [5]Я в потерях :).
Вчера все сделал, разницу расписал, и уже хотел отправлять, но тут подумал.
Ведь там глобального NamedObjectList нету. вместо Name:= идет SetName итд.
Теперь к вам вопрос,- вы сделаете
1. новую версию USE_NAMES или
2. замените старую?
Мне кажется лучше заменить, т.к. USE_NAMES заведомо логически
неправильна (имена не могут быть одинаковы), да и судя по отсутствию отзывов
не многие пользуются именами (или очень немногие если не никто), скорее всего
из - за этого. Да и места в KOL меньше надо.
Мне к примеру лично имена нужны для создания мультиязыкового приложения, и
только (компонент которого делаю). Хотя может кто-то возразит?
Ну а если первое, то как назвать директиву? NEW_USE_NAMES что-ли?
Спрашиваю чтобы вам было меньше работы и соответственно изменения будут приняты быстрее.
Vladimir Kladov (2007-01-27 20:22:00) [6]Да все вы правильно рассуждаете. Если вам надо как в VCL, чтобы имя было уникально в пределах формы.
Psychedelic (2007-01-27 11:48:00) [7]Владимир ну скажите что - нибудь. Хотя бы Да или Нет :)
Psychedelic (2007-01-26 18:21:00) [8]
> Можете. Присобачьте. (Я же говорю: с именами не работаю,
> кроме отладки не использую).
Но тут тогда требуются уточнения, чтобы работа в утиль не пошла.
Для того чтобы присобачить к форме нужно:
1. В Pcontrol добавить NamedObjectList.
2. В NewForm в KOL_ASM.inс добавить создание этого списка.
3. Вместо Result.Button1.Name := 'Button1' нужно сделать public
процедуру SetName (Form:Pcontrol (или указатель на Plist), Name).
Т.е. нужно будет исправить в зеркале.
Это основное. Я правильно рассуждаю? Может что то забыл?
Может у Вас будут другие идеи?
Если да, тогда я берусь.
Vladimir Kladov (2007-01-26 14:59:00) [9]Можете. Присобачьте. (Я же говорю: с именами не работаю, кроме отладки не использую).
Psychedelic (2007-01-26 00:01:00) [10]Может NamedObjectsList подцепить к каждой форме (и findObj соответственно)?
Тогда будет несколько плюсов:
Время загрузки программы уменшиться, т.к. не нужно будет перелопачивать
все объекты.
Иcчезнет проблема дубликатов сама собой.
А?