void (int N, AnsiString NewCaption)
{
AnsiString C_Name=AnsiString("Label") + IntToStr(N);
for (int i = 0; i < Form1->ComponentCount; i++)
{
if (Form1->Components->ClassNameIs ("TLabel"))
{
if( ((TLabel *)Form1->Components)->Name == C_Name)
{
((TLabel *)Form1->Components)->Name == NewCaption;
}
}
}
}
Доступ к свойству компонента по его имени
На форме есть несколько меток: Label1, Label2, Label3...
Необходимо в зависимости от значения цкелой переменной (например i) менять значение Caption у метки. Т.е. если i=1,то у Label1, если i=2, то у Label2.
Понятно, что это можно сделать просто оператором switch или обычным if. А как бы извернуться и получать доступ к Caption, если знаешь имя метки?
Необходимо в зависимости от значения цкелой переменной (например i) менять значение Caption у метки. Т.е. если i=1,то у Label1, если i=2, то у Label2.
Понятно, что это можно сделать просто оператором switch или обычным if. А как бы извернуться и получать доступ к Caption, если знаешь имя метки?
Сделай им Name 1, 2, 3. Воспользуйся свойством Tag. Не очень понятна задача. По-подробнее, если можно.
Пардон. Name, например: lbl1, lbl2, lbl3. А дальше, отбрасывая первые три символа, знать соответствие с переменной i
Цитата:
Originally posted by Mark
Сделай им Name 1, 2, 3. Воспользуйся свойством Tag. Не очень понятна задача. По-подробнее, если можно.
Сделай им Name 1, 2, 3. Воспользуйся свойством Tag. Не очень понятна задача. По-подробнее, если можно.
Формально задача звучит так. Я знаю имя компонента и его тип. Как получить доступ к его свойствам?
Например во время работы программы я получаю строковую переменную S="Label3". Как мне получить доступ к компоненту Label3 в программе не перебирая в программе все компоненты такого типа? Можно поподробнее про Tag? Как его использовать в этом случае?
Я бы передавал не строковую, а указатель на TLabel.
Цитата:
Originally posted by Mark
Я бы передавал не строковую, а указатель на TLabel.
Я бы передавал не строковую, а указатель на TLabel.
Надо строковую - имя компонента.
Если можно напишите фрагмень кода как такую штуку реализовать.
Вроде так.
TLabel *MyLabel = (TLabel*)(FindComponent(Form1->Edit1->Text));
MyLabel->Caption = "Нашел!";
То есть в Edit'е введено имя Label'а, и ему меняем Caption.
TLabel *MyLabel = (TLabel*)(FindComponent(Form1->Edit1->Text));
MyLabel->Caption = "Нашел!";
То есть в Edit'е введено имя Label'а, и ему меняем Caption.
Срослось что ли?
Рассказал бы по-подробнее, как ты дошел до такой проблемы. На мой взгляд этот способ не очень хорош. Возможно где-то в самом подходе ошибка.
Рассказал бы по-подробнее, как ты дошел до такой проблемы. На мой взгляд этот способ не очень хорош. Возможно где-то в самом подходе ошибка.
Цитата:
Originally posted by Mark
Срослось что ли?
Рассказал бы по-подробнее, как ты дошел до такой проблемы. На мой взгляд этот способ не очень хорош. Возможно где-то в самом подходе ошибка.
Срослось что ли?
Рассказал бы по-подробнее, как ты дошел до такой проблемы. На мой взгляд этот способ не очень хорош. Возможно где-то в самом подходе ошибка.
Да, спасибо, всё заработало. Есть пять резервуаров(по видам бензина). У них куча свойств, которые должен видеть юзер. Это и есть метки. Для рисования диаграмм и заполнения свойств используется ф-я, в которую передайтся код продукта. Для обновления информации как раз и использовал FindComponent. Если просто перебирать метки
Switch(ProdCode)
{
case 1:....break;
case 2:....break;
.......
}
то код получается громоздкий и неудобочитаемый.:-x А так всё очень наглядно.:cool: А почему тебе не нравится?
То есть если мы говорим про ООП, то задча такая: привязать к каждому объекту класса свое собственное представление, причем все представления должны/могут существовать одновременно. Ну если задача не особо навороченная, то решение вроде как и нормальное.
К стати, кто знает красивое решение?
А не нравится мне то, что наша с тобой обожаемая функция скорее всего не изобретая гениальных алгоритмов перебирает все компоненты на форме пока не находит требуемый по имени, а далее возвращает указатель на него. То есть от switch мы не далеко ушли. Вот если бы в твой обработчик прдеставления сразу падал требуемый указатель, то никакого высокоинтеллектуального прямого перебора не было бы вообще.
К стати, кто знает красивое решение?
А не нравится мне то, что наша с тобой обожаемая функция скорее всего не изобретая гениальных алгоритмов перебирает все компоненты на форме пока не находит требуемый по имени, а далее возвращает указатель на него. То есть от switch мы не далеко ушли. Вот если бы в твой обработчик прдеставления сразу падал требуемый указатель, то никакого высокоинтеллектуального прямого перебора не было бы вообще.
Цитата:
Originally posted by Mark
То есть если мы говорим про ООП, то задча такая: привязать к каждому объекту класса свое собственное представление, причем все представления должны/могут существовать одновременно. Ну если задача не особо навороченная, то решение вроде как и нормальное.
К стати, кто знает красивое решение?
А не нравится мне то, что наша с тобой обожаемая функция скорее всего не изобретая гениальных алгоритмов перебирает все компоненты на форме пока не находит требуемый по имени, а далее возвращает указатель на него. То есть от switch мы не далеко ушли. Вот если бы в твой обработчик прдеставления сразу падал требуемый указатель, то никакого высокоинтеллектуального прямого перебора не было бы вообще.
То есть если мы говорим про ООП, то задча такая: привязать к каждому объекту класса свое собственное представление, причем все представления должны/могут существовать одновременно. Ну если задача не особо навороченная, то решение вроде как и нормальное.
К стати, кто знает красивое решение?
А не нравится мне то, что наша с тобой обожаемая функция скорее всего не изобретая гениальных алгоритмов перебирает все компоненты на форме пока не находит требуемый по имени, а далее возвращает указатель на него. То есть от switch мы не далеко ушли. Вот если бы в твой обработчик прдеставления сразу падал требуемый указатель, то никакого высокоинтеллектуального прямого перебора не было бы вообще.
Задачи подобные этой не совсем относятся к ООП, а скорее к OOA&D (объектно ориентированный анализ и проектирование). Я бы настоятельно рекомендовал всем программистам изучить связанные с этим документы и наработки (парретны проектирования). Поверьте, после этого вы взгляните на Мир по-другому. Очень красивые и обоснованные решения.
Достаточно много книг по этой тематике, есть и электронные.
http://ooad.asf.ru/index.asp?Url=patterns
А использование имен элементов - очень некрасивое решение, вы ж не на бейсике или яве пишете.
Цитата:
Originally posted by Green
Задачи подобные этой не совсем относятся к ООП, а скорее к OOA&D (объектно ориентированный анализ и проектирование). Я бы настоятельно рекомендовал всем программистам изучить связанные с этим документы и наработки (парретны проектирования). Поверьте, после этого вы взгляните на Мир по-другому. Очень красивые и обоснованные решения.
Достаточно много книг по этой тематике, есть и электронные.
http://ooad.asf.ru/index.asp?Url=patterns
А использование имен элементов - очень некрасивое решение, вы ж не на бейсике или яве пишете.
Задачи подобные этой не совсем относятся к ООП, а скорее к OOA&D (объектно ориентированный анализ и проектирование). Я бы настоятельно рекомендовал всем программистам изучить связанные с этим документы и наработки (парретны проектирования). Поверьте, после этого вы взгляните на Мир по-другому. Очень красивые и обоснованные решения.
Достаточно много книг по этой тематике, есть и электронные.
http://ooad.asf.ru/index.asp?Url=patterns
А использование имен элементов - очень некрасивое решение, вы ж не на бейсике или яве пишете.
Да нет вопросов. Я и предлагаю шаблон обсудить, если кто-то видел/сделал.