Существует следующая проблема. Есть большие участки кода которые повторяются по два раза... и различаются лишь в одной строчечке...
Что-то наподобие такого...:
Button1. Caption:='Text';
Button1.Left:=111;

.....



Button2. Caption:='Text';
Button2.Left:=111;


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


К примеру в переменую perem  := TOrder(от чего-то там) ну и сней делаются всякие там штуки....
В таком же коде, отличающемся только одной строчкой в которой perem  := чё-то другое пресваивается и уже с этим делаются теже всякие штучки....

Хотелось бы избавиться от этого дубляжа...




Это сообщение отредактировал(а) Veve - 7.12.2006, 20:06

имхо так

Это сообщение отредактировал(а) Romikgy - 7.12.2006, 20:23

Ну да с Buttonом там много существует решений, но как я ранее говорил проблемма не в Buttonaх.... 

Мои два обьекта совсем других типов....

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

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

Rodman, почти, только у TObject нет таких свойств лучше юзать более высокого предка, например,
TComponent, TControl, TWinControl, т.е. будет

а вот с caption проблема, он появляется только у конечного класса.

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

alexeis1, можно написать свой класс, "делающий всякие штуки", от которого унаследовать классы, заточенные уже под конкретные задачи.

Добавлено @ 20:57 
вообще, в целом, есть всего два подхода: классический модульный, т.е. выделение общего кода в отдельные процедуры/модули, и ООП-шный. предпочтение того или иного зависят уже от конкретики решаемой задачи. если речь идёт только о том, чтобы изменить два свойства у двух контролов - писать свои классы, наверное, смысла нет. если о том, чтобы объеденить объекты с похожей логикой работы - то здесь, наверное, ООП - оптимум.

x77, можно, но тогда для удобства прийдется переписывать пол палитры компонентов, а потом еще их регистрировать. Мороки много... Иногда если задача не слишком сложная проще выкрутится 

Вот так выводить.

Или в массив

Писал здесь могут быть ошибки.

Но это особо не уменьшит код я в своёи проекте где 5000 строк также делал оптимизацию все что болеш одного выносил в отдельную процедуру только запутался в конечном результате  а толку экономия 50кб сам проект весил 870кб потом 820кб  так что это особой выгоды не даст хотя и выглядит более крассиво  

Это сообщение отредактировал(а) ivan219 - 8.12.2006, 21:23

Зато это позваляет избавиться от багов... Всем спасибо! 

Это сообщение отредактировал(а) Veve - 11.12.2006, 17:11