Как подавить реакцию TTreeView на двойной клик?

← →
АлександрМ (2007-07-05 01:42) [0]

TTreeView при двойном клике сворачивает или разворачивает ту ветку на которой был выполнен этот двойной клик. На событие OnDblClick сделан свой обработчик. И не нужно, чтобы ветка при этом закрывалась или открывалась (пусть пользователь сворачивает или разворачивает её только с помощью кнопок - и +). Подскажите, пожалуйста, как это сделать.

← →
ЮЮ © (2007-07-05 04:18) [1]

Например так: (работают кнопки "*", "-" и "+" с NumPad)
unit Unit1; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, ComCtrls; type TForm1 = class(TForm) TreeView1: TTreeView; procedure TreeView1Collapsing(Sender: TObject; Node: TTreeNode; var AllowCollapse: Boolean); procedure TreeView1Expanding(Sender: TObject; Node: TTreeNode; var AllowExpansion: Boolean); procedure TreeView1KeyDown(Sender: TObject; var Key: Word; Shift: TShiftState); private { Private declarations } FLegalWay: boolean; public { Public declarations } end; var Form1: TForm1; implementation {$R *.dfm} procedure TForm1.TreeView1Collapsing(Sender: TObject; Node: TTreeNode; var AllowCollapse: Boolean); begin AllowCollapse := FLegalWay; end; procedure TForm1.TreeView1Expanding(Sender: TObject; Node: TTreeNode; var AllowExpansion: Boolean); begin AllowExpansion := FLegalWay; end; procedure TForm1.TreeView1KeyDown(Sender: TObject; var Key: Word; Shift: TShiftState); begin FLegalWay := (Key = VK_ADD) or (Key = VK_SUBTRACT) or (Key = VK_MULTIPLY); end; end.

← →
АлександрМ (2007-07-05 12:34) [2]

Ага, спасибо.

← →
Инс © (2007-07-05 13:29) [3]

Можно так - ДО объявления формы пишем

TTreeView = class(ComCtrls.TTreeView) private procedure WMLButtonDblClk(var Message: TWMLButtonDblClk); message WM_LBUTTONDBLCLK; end;

а вот реализация метода WMLButtonDblClk

procedure TTreeView.WMLButtonDblClk(var Message: TWMLButtonDblClk); var Rect: TRect; begin if Assigned(Selected) then begin Rect:=Selected.DisplayRect(true); Rect.Left:=Rect.Left - Indent; if PtInRect(Rect,Point(Message.XPos,Message.YPos)) then if Assigned(OnDblClick) then OnDblClick(Self); end; end;

← →
Ega23 © (2007-07-05 13:56) [4]

> TTreeView = class(ComCtrls.TTreeView)

Я бы своего подчинённого убил за такое.

← →
Инс © (2007-07-05 14:18) [5]

А здря. Иногда, если нужно лишь слегка изменить функциональность компонента, нет смысла регистрировать его в палитре (у меня практически в каждом проекте такое требуется) - иначе палитра превратиться в свалку компонентов, которые нужны только в одном проекте. Создавать в рантайм - неудобно. А такой "обман среды" - ИМХО изящен и безопасен, впрочем, каждый сам решает для себя.

← →
Ega23 © (2007-07-05 14:36) [6]

> А здря. Иногда, если нужно лишь слегка изменить функциональность
> компонента, нет смысла регистрировать его в палитре (у меня
> практически в каждом проекте такое требуется) - иначе палитра
> превратиться в свалку компонентов, которые нужны только
> в одном проекте. Создавать в рантайм - неудобно. А такой
> "обман среды" - ИМХО изящен и безопасен, впрочем, каждый
> сам решает для себя.
>

TTreeView - это TTreeView и никак иначе. Со всеми хелпами и правилами работы. Надо что-то своё - наследуйся от TCustomTreeView наздоровье.

← →
Инс © (2007-07-05 14:48) [7]

> TTreeView - это TTreeView и никак иначе. Со всеми хелпами
> и правилами работы. Надо что-то своё - наследуйся от TCustomTreeView
> наздоровье.

Уважаемый, Ваше мнение по этому вопросу вполне понятно. Свое я никому не навязываю, считаю, что мой подход также имеет право на существование, так как (аргументы привел выше). Так что не будем спорить, бесполезно, каждый останется при своем. К тому же, этот трюк уже миллион раз обсуждался и ничего нового в данном топике не прозвучало.

← →
Инс © (2007-07-05 14:55) [8]

И в дополнение... Я прекрасно понимаю, что программировать можно двумя способами:
1. Что б работало
2. Правильно
Но всякое случается, инагда - сроки поджимают, иногда просто не хочется замосоривать палитру "одноразовым" компонентом. А выход есть. Кстати, чтобы не гадить в модуле с формой, можно данный код вынести в другой юнит, и в списке uses объявить последним, либо хотя бы после юнита, где содержиться класс-предок.

Данный трюк не намного хуже, чем то же объявление пустого класса наследника и приведение к нему для доступа к protected-свойствам и методам. Подобными "трюками" иногда даже грешила Borland, а значит - индульгенция получена.

← →
Ega23 © (2007-07-05 15:15) [9]

> Данный трюк не намного хуже, чем то же объявление пустого
> класса наследника и приведение к нему для доступа к protected-
> свойствам и методам. Подобными "трюками" иногда даже грешила
> Borland, а значит - индульгенция получена.

Существенная разница. Создать класс-однодневку и создавать его в ран-тайме - это вполне допустимый вариант.
А вот так над палитрой компонентов насильничать... Тогда чё уж там, давай сразу в VCL править.

← →
Инс © (2007-07-05 15:19) [10]

> А вот так над палитрой компонентов насильничать...

Как раз таки наоборот, палитра остается нетронутой. Писать наследника с регистрацией в палитре - замусоривать последнюю, не регистрировать а создавать в рантайм - неудобно + замусоривание кода. А так - все чисто.

> Тогда чё уж там, давай сразу в VCL править.

Существенная разница ;) Править VCL - это значит полная несовместимость с Delphi, установленными на других машинах.

← →
Ega23 © (2007-07-05 15:23) [11]

> Как раз таки наоборот, палитра остается нетронутой. Писать
> наследника с регистрацией в палитре - замусоривать последнюю,
> не регистрировать а создавать в рантайм - неудобно + замусоривание
> кода. А так - все чисто.

Ничего не чисто. У тебя семантика остаётся неизменной при явной подмене сущностей.

← →
Инс © (2007-07-05 15:29) [12]

Эстетические аспекты меня мало волнуют, ибо я сам понимаю все недостатки данного подхода. Мне интересны технические недостатки, которые перекроют технические достоинства.

← →
Ega23 © (2007-07-05 15:47) [13]

> Инс © (05.07.07 15:29) [12]
>
> Эстетические аспекты меня мало волнуют, ибо я сам понимаю
> все недостатки данного подхода. Мне интересны технические
> недостатки, которые перекроют технические достоинства.

Вам доводилось заниматься командной разработкой большого проекта? А поддерживать чужой код?
Всегда ли вы, видя объявление
var bmp : TBitmap;
лезете посмотреть: а является ли TBitmap стандартным классоом TBitmap, или какой-нибудь Вася Пупкин, писавший этот код год назад, взял да и перекрыл его? Для решения своих маленьких нужд?
Не нравится TBitmap? Хорошо, пусть будет TADODataSet. Или TButton.

← →
Инс © (2007-07-05 15:54) [14]

> Вам доводилось заниматься командной разработкой большого
> проекта? А поддерживать чужой код?

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

← →
Инс © (2007-07-05 16:04) [15]

Специально для эстетов: если определенное поведение (как например, реакция TreeView на двойной клик) не устраивает в определенном контроле (а не во всех контролах данного типа) - можно просто в рантайм подменить WindowProc.

← →
Ega23 © (2007-07-05 16:07) [16]

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

А не надо регистрировать. Надо в ран-тайм создавать. А вот если такое создание сплошь и рядом идёт - то тогда сам Баал велел компонент ставить.

> Еще раз повторю, что такой трюк при умелом использовании
> вполне безопасен (если конечно класс нужно подкорректировать
> чуть-чуть, а не капитально).

Ещё раз повторяю, что такой трюк уместен на столько же, насколько уместен выход из рекурсивной процедуры через goto.

← →
Инс © (2007-07-05 16:16) [17]

> Ещё раз повторяю, что такой трюк уместен на столько же,
> насколько уместен выход из рекурсивной процедуры через goto.

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

← →
Инс © (2007-07-05 16:27) [18]

Ссылки на обсуждения данного приема, дабы нам не повторяться:
Первоисточник - http://ww.delphikingdom.com/asp/answer.asp?IDAnswer=35814
http://www.delphikingdom.com/asp/articles_forum.asp?ArticleID=1296
http://www.delphikingdom.com/asp/answer.asp?IDAnswer=47497
http://www.delphikingdom.com/asp/answer.asp?IDAnswer=49421

← →
Ega23 © (2007-07-05 16:29) [19]

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

Да делайте что хотите, Вы в своём праве. Зачем только такие советы начинающим давать?

З.Ы. ВОГ-17 можно использовать как ручную гранату контактного действия. Надо всего лишь перед броском об что-нибудь твёрдое её ударить, чтобы на боевой взвод встала.
Прямых запретов нигде нет. Однако почему-то её таким образом крайне редко используют. Вот интересно, а почему?

← →
Ega23 © (2007-07-05 16:54) [20]

> Ссылки на обсуждения данного приема, дабы нам не повторяться:
>
> Первоисточник - http://ww.delphikingdom.com/asp/answer.asp?IDAnswer=35814
> http://www.delphikingdom.com/asp/articles_forum.asp?ArticleID=1296
> http://www.delphikingdom.com/asp/answer.asp?IDAnswer=47497
> http://www.delphikingdom.com/asp/answer.asp?IDAnswer=49421

Прочитал.
Из сторонников увидел только Вас да восторги Geo, которому понравилось решение (решение красивое, спорить не буду. Но - только для личного пользования с полным пониманием того, что ты делаешь).
Из противников - Антоха Григорьев, что уже немало. Хотелось бы мнение АП, ИШ или ЮЗ на этот счёт услышать.

← →
Инс © (2007-07-05 17:00) [21]

Из сторонников можно еще DRON-а назвать, что также немало ;)
ЮЗ в одной из ссылок предлагал решение с Hack-классом, что не сильно далеко уходит от данной темы, хотя, интересно узнать мнение именно по этому поводу.

← →
Ega23 © (2007-07-05 17:01) [22]

> ЮЗ в одной из ссылок предлагал решение с Hack-классом, что
> не сильно далеко уходит от данной темы, хотя, интересно
> узнать мнение именно по этому поводу.

Hack-класс - нормальное решение. Но идентификатор данного класса создаётся с другим семантическим названием.
В отличие от.

← →
Инс © (2007-07-05 17:04) [23]

> Hack-класс - нормальное решение. Но идентификатор данного
> класса создаётся с другим семантическим названием.
> В отличие от.

Ну, как сказать, нормальное. Там просто проблема в другом. Доступ к protected полям закрыт идеологией ООП. А там мы ее нарушаем. И здесь мы нарушаем некоторые каноны, так что, приемы близки, ИМХО.

← →
{RASkov} © (2007-07-05 17:11) [24]

> Ega23

> Инс

Хватит спорить :) Присядте где нибудь вместе, и за кружечкой пива поговорите. :о)

← →
Инс © (2007-07-05 17:17) [25]

> Хватит спорить :)

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

← →
sdts (2007-07-05 17:23) [26]

Для
> Ega23 © (05.07.07 17:01) [22]

а вы сами то [13] ?

← →
Ega23 © (2007-07-05 17:52) [27]

> а вы сами то [13] ?

Знаешь, если я вижу переменную btn : TButton, то я буду УВЕРЕН, что это именно стандартный TButton. Со всеми его методами, свойствами и событиями.
Вот если я увижу TMyButton или THackButton - то тогда да, обязательно залезу и посмотрю, что это такое. Но не раньше.
Просто Инс © предлагает подменять существующие сущности своими. А я говорю, что их подменять - нельзя. Надо создать новую сущность. Пусть очень похожую. Но - новую.

← →
Инс © (2007-07-05 17:56) [28]

> Ega23 © (05.07.07 17:52) [27]

Не умножать количество сущностей без надобности - Бритва Оккама. Известный принцип. Это я про другую сторону вашего утверждения про сущности...

← →
b z (2007-07-05 18:18) [29]

> Ega23 © (05.07.07 17:52) [27]

ведь не зря упямянул [13], т.к. когда начинть проект - это одно, а вот сапорт - другое ... ;)

← →
Desdechado © (2007-07-05 18:50) [30]

Я против таких маневров с именами классов.
Есть подозрения, что проекты с пакетами работать будут некорректно.
А уж то, что DLL, в которой хранится свое описание класса, будет работать некорректно по отношению к EXE с таким модифицированным описанием - это 100%.

← →
Инс © (2007-07-05 19:27) [31]

> [30] Desdechado © (05.07.07 18:50)

Вы не любите кошек? Вы просто не умеете их готовить! ;)

← →
{RASkov} © (2007-07-05 20:01) [32]

А я ни с кем не работаю... пишу себе так.... для души и себя... и один.
И частенько использую метод "подмены" предложенный Инс. Если эта подмена происходит в другом модуле (См[8]) то комментирую эти веСЧи...:)
Ну в самом деле... в простеньких проектах это удобнее, чем создание их(контролов) в рантайм или еще хуже отдельным компонентом...
Спор бесполезен... так как оба правы и оба не правы в одно и тоже время :) Все зависит от конкретного проекта.
:о)

> [31] Инс © (05.07.07 19:27)
> Вы не любите кошек? Вы просто не умеете их готовить! ;)

Не отступай :)

← →
b z (2007-07-05 20:41) [33]

> так как оба правы и оба не правы в одно и тоже время :)

> Не отступай :)

← →
Desdechado © (2007-07-05 21:33) [34]

> Инс © (05.07.07 19:27) [31]
Представь себе программу с плагинами. Плагины пишутся любым желающим. А ты у себя в программе попереопределял половину классов, а потом толкаешь их в эти плагины в качестве переметров. Что имеем? Правильно, неопознанные ошибки. Собственно, как и в случае компиляции плагинов в других версия дельфи.

← →
Инс © (2007-07-05 22:05) [35]

> [34] Desdechado © (05.07.07 21:33)

А причем тут плагины? И как регистрация классов в палитре под другим именем или создание их в рантайм поможет твоей проблеме? Спор ведь именно об этом. И еще. Ткни меня пальцем в мой пост, где я предлагаю переопределять половину классов и пихать их повсюду куда ни попадя. Я утверждаю, что в рамках аккуратного обдуманного использования этот способ имеет право на существование. А про плагины и DLL ты первый заговорил, так как видимо соображалка за границы собственного проекта выходить категорически отказывается.

← →
{RASkov} © (2007-07-05 22:14) [36]

> [35] Инс © (05.07.07 22:05)

От одного отбился... тут другой :))
>
Чесслова...> Как подавить реакцию TTreeView на двойной клик?
реакцию уже подавили давно :) Хватит спорить :)
Ветка, с этим бесконечным спором, уже смех вызывает. :)

← →
Desdechado © (2007-07-05 22:25) [37]

Инс © (05.07.07 22:05) [35]
Плагины - пример неприменимости твоих подходов, да еще и пример возникновения скрытых ошибок.
О регистрации в палитре говорил только ты, это у тебя фантазии только на 2 вещи хватает, а моей аналитической соображалке вполне по силам гораздо более серьезные вещи.
А спор идет, если ты не понял, о противоестественном желании написать на своем изделии чужой товарный знак, обманивая всех и себя самого.

← →
Инс © (2007-07-05 22:43) [38]

> О регистрации в палитре говорил только ты

Рекомендую перечитать ветку с самого начала. Данный метод был предложен именно как альтернатива регистрации классов в палитре при небольшой модификации базового. Именно об этом и шел спор с г-ном Ega23. А насчет плагинов - так компилятор и не пропустит, если функция требует в качестве параметра ComCtrls.TTreeView, а ты передаешь свой TreeView. Так как классы проверяются на совместимость не путем проверки имен, а путем проверки указателя на VMT. Или ты имеешь в виду что-то другое? Тогда поясняй подробнее.

← →
Инс © (2007-07-05 22:46) [39]

> А насчет плагинов - так компилятор и не пропустит, если
> функция требует в качестве параметра ComCtrls.TTreeView,
> а ты передаешь свой TreeView.

Наоборот, разумеется...

← →
Инс © (2007-07-05 23:04) [40]

> Плагины - пример неприменимости твоих подходов

Примеры неприменимости той или иной технологии есть всегда. Например, SendMessage неприменим, в случае посылки сообщения спящему потоку, ожидающему освобождения объекта твоим потоком. Критическая секция неприменима при синхронизации потоков различных процессов. Отвертка неприменима в случае, когда нужно забить гвоздь в стену. Но если есть хотя бы одна область, где тот или иной метод применим и обоснован - он имеет право на существование. Так что твою позицию считаю необоснованной.

← →
GeoJ (2007-07-06 12:50) [41]

> <...> восторги Geo, которому понравилось решение <...>
Господа! Мир -- вообще тесен. А интернет -- особенно. Так что лучше все же быть поаккуратнее с высказываниями относитель но конкретных людей: они могут это увидеть. Это я к тому, что хоть убей, не помню своих сообщений с восторгами, так как эйфория прошла достаточно давно, когда этот способ только был придуман.

Было всего лишь конструктивное обсуждение возможностей еприменения данного способа. Именно поэтому Инс привел ссылки. Чтобы народ не повторялся в обсуждении.

>>> Из противников - Антоха Григорьев
Если Вы читали внимательно, то должны были заметить, что неприятие у Антона всего лишь на эстетическом уровне (ну, не нравится). То есть, если понимаешь что, как, зачем и почему, то использование данного метода вполне допустимо и влечет за собой не больше опасностей, чем цикло for-to-do.

>>> TTreeView - это TTreeView и никак иначе
Вообще-то, по ООП TTreeView так и останется TTreeView. Только отдельные строчки будут красного цвета ;-)

И еще... Система разработки состоит не только из среды визуального проектирования, но и и из кода на языке программирования. Я Вам навскидку могу привести несколько устоявшихся общепризнанных приемов программирования, которые грешат тем же самым: трудностью понимания того, о чем именно идет речь. Но все пользуются и не жужжат.

← →
_MaSteR_NN_ (2007-07-06 13:27) [42]

Да уж, мир тесен :)

← →
MetalFan © (2007-07-06 14:53) [43]

я тоже считаю, что так объявлять не совсем корректно
TTreeView = class(ComCtrls.TTreeView)
лучше, имхо, хотябы так:
{THack|TMy|TSpec|etc}TreeView = class(ComCtrls.TTreeView)
а если другой человек будет читать код, и случайно не заметит описание одноименного со стандартным класса?
и уж тем более не стоит рекомендовать писать так новичку. дурной тон.
жаль тут нельзя голосование устроить))))

← →
Инс © (2007-07-06 15:19) [44]

> лучше, имхо, хотябы так:

Вы не просекли фишки. Так как Вы предлагаете написать - безусловно правильно, но фишки не будет. Тут же прикол в чем? В том, что среда "думает", что используется класс с палитры, а мы его подменяем своим, и в рантайм именно наш и будет создан. Если написать другое имя, отличное от имени предка, то придется либо регистрировать его в палитре, либо создавать в рантайм.

← →
MetalFan © (2007-07-09 00:27) [45]

> Вы не просекли фишки

точно, не просек)
но все равно интуитивно мне такой подход не нравится)))

← →
Ega23 © (2007-07-09 11:49) [46]

Да делайте так, как считаете нужным. Хоть goto используйте (сам часто использую, правда в TSQL).
Только метод-то всё равно варварский.

← →
GeoJ (2007-07-09 18:29) [47]

Профессионально занеимаюсь программированием с 1991 года. И на всех ОС на всех языках программирования всегда присутствовали приемы, которые всеми расценивались как "плохие", но, тем не менее, использовались. С кучей оговорок, требований к аккуратности использования и рекомендациями не трогать без необходимости. Потому что давали определенные преимущества, которых нельзя было достичь законными средствами.

Если мне в рамках данного конкретного проекта требуется создать модифицированный ListBox, я сдлеаю производный класс, а не буду обвешивать многочисленными обработчиками событий стандартный TListBox. Только для того, чтобы отделить поведение списка от логики самой программы. И я не буду создавать этот ListBox в run-time, если на форме много компонент и их взаимное расположение, возможно, будет изменяться в процессе работы над проектом. И уж наверняка не буду регистрировать чуть-чуть модифицированный компонент в VCL (там и так куча лишнего), если он не потребуется для других проектов.

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

← →
Ega23 © (2007-07-09 18:57) [48]

> И я не буду создавать этот ListBox в run-time, если на форме
> много компонент и их взаимное расположение, возможно, будет
> изменяться в процессе работы над проектом.

Parent := ListBoxPanel; Align := alClient;
?

← →
{RASkov} © (2007-07-10 09:43) [49]

> [48] Ega23 © (09.07.07 18:57)
> Parent := ListBoxPanel;
> Align := alClient;

Ресурсоемко получается :) Два хэндла и оба получают сообщения.... только первому они практически не нужны...(
Олег, неужели ты всегда(во всех своих проектах) так(как советуешь) делаешь? И не разу не пользовал метод "подмены"... не верю :)
Хотя согласен - делать - это одно, а советовать такое - это другое.

> [47] GeoJ (09.07.07 18:29)
> Впрочем, если CodeGear добавит в IDE новую возможность (что-
> то типа дополнительной панели для классов, определенных
> в текущем проекте)

Интересная идея... :)

← →
MetalFan © (2007-07-10 09:52) [50]

> Ресурсоемко получается :) Два хэндла и оба получают сообщения.
> ...

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

← →
Ega23 © (2007-07-10 10:04) [51]

> Ресурсоемко получается :) Два хэндла и оба получают сообщения.
> ... только первому они практически не нужны...(
> Олег, неужели ты всегда(во всех своих проектах) так(как
> советуешь) делаешь? И не разу не пользовал метод "подмены".
> .. не верю :)

Если уж настолько сильно приспичивает до какого-нибудь Canvas достучаться, который в protected сидит, то либо нследуюсь от TCustom... либо от реального класса. Но это - крайне редко.

Если честно, то у меня редко какой грид (TreeView, Memo и пр.) не лежит на панели. Процентах в 70 - точно.
Подмену - нет, не делаю. Как правило, хватает стандартных компонентов с обработчиками.
Чатос приходится использовать TEdit, но такой, чтобы только цифры можно печатать было. Но даже для него просто пишу метод формы и назначаю сразу куче Edit"ов в качестве обработчика.

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

← →
{RASkov} © (2007-07-10 10:07) [52]

> [50] MetalFan © (10.07.07 09:52)
> зато не надо изврат с одноименными классами без нужды использовать

У меня есть в программе наипростейшее окно Абоут и в нем, например, один единственный компонент и весь код модуля это изменение некоего стандартного действия этого компонента, и что? Мне для этого нужно новый компонент регистрировать в палитре? или создавать его в рантайме? или приведение типов делать? А не проще подмену? :)

Это я не про ресурсоемкость, а вобще по спору :)

> прям таки ресурсоемко? одним хэндлом больше, одним меньше

Ну а здесь вопрос отдельный и не нажно пользоваться при написании программ - убеждением того, что компы сейчас мощные ресурсов хватит нв все...
или давайте все так писать и что? запустили мою и твою прогу и ОС сдохла... :)

← →
GeoJ (2007-07-10 10:23) [53]

> Parent := ListBoxPanel;
> Align := alClient;
> ?

Эт, конечно, замечательно, когда компонент можно растянуть по размерам родителя. А если проектируется диалоговое окно, в котором куча компонент. Причем каждому нужно аккуратно подогнать размеры и положение, то тогда еще добавиться и задание координат, щирины и высоты. А потом выяснится, что соседний компонент требуется чуть-чуть растянуть, так как в него не помещается то, что предполагалось. И снова лезем в код и подгоняем координаты и размеры.

Ну и раздражает меня обработчикм FormCreate, в котором сплошные кпиейты и инициализация.

> Как правило, хватает стандартных компонентов с обработчиками.

Везет! Что я могу еще сказать ;-)

Реальный проект. В разных местах должны быть размещены дбгриды со специфическими запросами для представления древовидных структур (что-то типа панели Нортон Командера). Можно, конечно, в каждом модуле обвесить каждый дбгрид обработчикамивсяких событий. Но за всем этим хламом теряется основная логика модуля. Так почему не включить это все в компонент и не вынести в отдельный модуль? Мы же с ООП работаем, а не с Фортраном.

> Но начинающим я бы такое советовать не стал

Вот тут, наверное, почти согласен. Советовать то можно (новичкам тоже нужно расти), но не ограничиваться тупым приведением кода, а дать развернутый ответ с объяснением того, что это искусственный прием обусловенный тем-то и тем-то.

← →
Ega23 © (2007-07-10 10:25) [54]

> В разных местах должны быть размещены дбгриды со специфическими
> запросами для представления древовидных структур (что-то
> типа панели Нортон Командера). Можно, конечно, в каждом
> модуле обвесить каждый дбгрид обработчикамивсяких событий.
> Но за всем этим хламом теряется основная логика модуля.
> Так почему не включить это все в компонент и не вынести
> в отдельный модуль?

Ну так и надо делать, кто спорит-то?
Но вот взять и стандартный DBGrid таким подменить - это ужасно.

← →
Инс © (2007-07-10 10:37) [55]

Ладно, господа, может завязываем? ;-) А то повторяться уже начали. Обсуждение получилось, есть два взгляда, каждый - обоснован, споряшие стороны что-то из обсуждения вынесут, да и читателям есть пища для ума. Хотя, допускаю, что мой уважаемый тезка (GeoJ) включился в дискуссию чуть позже и ему еще есть что добавить...

← →
GeoJ (2007-07-10 11:25) [56]

> Но вот взять и стандартный DBGrid таким подменить - это ужасно.

Алтернативы? Лезть на Torry и искать компонент, в котором данная функциональность уже реализована? Либо писать компонент самому. И в том, и в другом случае потребуется добавлять новый компонент в палитру. Пардон, но у меня куча мелких проектов, и если я для каждого проекта буду необходимые компоненты регистрировать в палитре (хотя нужны они только на один раз), то будет вообще полная каша.

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

← →
Инс © (2007-09-06 10:31) [57]

Кстати, нашелся еще один аргумент "за" ;-)

> Знаешь, если я вижу переменную btn : TButton, то я буду
> УВЕРЕН, что это именно стандартный TButton. Со всеми его
> методами, свойствами и событиями.

В последних версиях компилятора теперь этот обман можно делать вполне легально - class helper.

← →
Ega23 © (2007-09-06 10:38) [58]

> В последних версиях компилятора теперь этот обман можно
> делать вполне легально - class helper.

У меня Delphi 7 и когда поменяется - только Ктулху знает... :)))

← →
Инс © (2007-09-06 10:46) [59]

> У меня Delphi 7 и когда поменяется - только Ктулху знает.
> .. :)))

Дык у меня тоже ;)

← →
Lacmus © (2007-09-06 11:55) [60]

> Противники использования Инс © (05.07.07 13:29) [3]

Как вы относитесь к использованию пакетов в своих приложениях ?

← →
Инс © (2007-09-06 12:18) [61]

> Как вы относитесь к использованию пакетов в своих приложениях
> ?

Это ко мне вопрос? Никак не отношусь, я их не использую, а что? :)

← →
Инс © (2007-09-06 12:20) [62]

> Противники использования Инс ©

Это вы представились, или это к ним обращение? :)

← →
Lacmus © (2007-09-06 12:30) [63]

Как все сложно :-)

Вопрос к противникам использования, публикации кода, описанного в Инс © (05.07.07 13:29) [3]

← →
Shirson © (2007-09-06 22:53) [64]

> Ega23 © (05.07.07 16:29) [19]
> З.Ы. ВОГ-17 можно использовать как ручную гранату контактного действия. > Надо всего лишь перед броском об что-нибудь твёрдое её ударить, чтобы на боевой взвод встала.
> Прямых запретов нигде нет. Однако почему-то её таким образом крайне редко используют. Вот интересно, а почему?
>

Не флейма ради, а истины для.

ВОГ становится на боевой взвод вследствии воспламенения метательного заряда. Если её серьёзно ударить о что-нибудь твёрдое, то первым делом сработает как раз метательный заряд (нитроглицериновый порох). Учитывая нахождения этой штуки в лапке при ударе, это прямая дорога к Дарвиновской премии.

Пример неудачен, потому что его применение заканчивается проблемами в десятки раз чаще, чем наоборот. А с предметом спора ситуация обратная - проблемы могут возникнуть лишь в некоторых, специфических условиях, да ещё и не у всех :)

> Как вы относитесь к использованию пакетов в своих приложениях
> ?
>

Использовал один раз, очень давно. Флешек тогда не было, а программу доделанную, исправленную, измененную и т.п. приходилось возить с собой на объект. На 3.5" влазила. :-)

Но я не противник и не сторонник :-)

> Как вы относитесь к использованию пакетов в своих приложениях
> ?

Совпадение или нет, вам судить. От нечего делать, чистил свои закладки, избранные и т.п.
Наткнулся на:
"О пакетах времени выполнения:

стр. 535:
"Пакеты (packages) - это специальные динамически подсоединяемые биб- лиотеки, содержащие библиотеки визуальных компонентов и другие объекты, функции, процедуры и т.д. Эти DLL позволяют вам создавать очеь небольшие выполняемые мо- дули, обращающиеся за поддержкой к пакетам. Вы можете также скомпилировать в пакеты свои собственные компоненты и библиотеки. Файлы пакетов имеют расши- рение .dpl"
стр. 536:
"Так что если вы надумали использовать поддержку пакетов времени вы- полнения, то вместе со своим приложением вы должны поставлять пользователю скомпилированные файлы эих пакетов - файлы .dcp"
стр. 538:
"При разработке приложений с поддержкой пакетов надо иметь в виду, что пакеты используют API Windows, содержащийся в различных DLL. Если какая-то из этих DLL у потребителя вашего программного продукта ошибочна или не соответст- вует по дате(версии), у вас могут возникуть проблемы. Их можно избежать, если проверять свое приложение на той системе, для которой оно предназначено, или на чистых установках Windows; тогда сможете быть уверенными, что оно будет выполняться без ошибок, и будете знать, что требуется вашему приложению для нормальной работы. В результате вы сможете убедиться, что включаете в поставку все необходимые файлы, или можете потребовать от пользователя работать на определенной версии операционной системы с определенными установками путей и.т.д."
".
:)))

Инс © (05.07.07 14:18) [5]
А здря. Иногда, если нужно лишь слегка изменить функциональность компонента, нет смысла регистрировать его в палитре (у меня практически в каждом проекте такое требуется) - иначе палитра превратиться в свалку компонентов, которые нужны только в одном проекте. Создавать в рантайм - неудобно. А такой "обман среды" - ИМХО изящен и безопасен, впрочем, каждый сам решает для себя.

Для этого достаточно сделать лишь один экземпляр каждого контрола со всеми нужными событиями: OnWndProc, OnCreateParams и т.п. (я как-раз так делаю, по мере надобности создавая свои наследники стандартных контролов)
В случае TTreeView=class(ComCtrls.TTreeView) можно было бы не обращать внимание на неочевидность, он еще и пораждает глюки. [u]У меня из-за него был AV.[/u] AV был в странном месте, но после замены извращений на компонент палитры все прекратилось. Это было в первой же программе, где я попытался такое использовать. Да и новосозданный TTreeView может повлиять на TTreeView в других формах, которые ожидают обычного TTreeView.

> И я не буду создавать этот ListBox в run-time, если на форме
> много компонент и их взаимное расположение, возможно, будет
> изменяться в процессе работы над проектом.

А и не надо:
with TMemoryStream.Create do try WriteComponent(TreeView1); TreeView1.Free; TreeView1:= TMyTreeView.Create(self); TreeView1.Parent:= self; ReadComponent(TreeView1); finally Free; end;
Писал на ходу, так что за работосособность не ручаюсь, но суть должна быть понятна.

> В случае TTreeView=class(ComCtrls.TTreeView) можно было
> бы не обращать внимание на неочевидность, он еще и пораждает
> глюки. [u]У меня из-за него был AV.[/u] AV был в странном
> месте, но после замены извращений на компонент палитры все
> прекратилось.

В общем то, это подтверждает лишь уже сказанные неоднократно в данной теме слова о том, что действительно не стоит показывать этот способ тем, кто не понимает что делает.

> Да и новосозданный TTreeView может повлиять на TTreeView
> в других формах, которые ожидают обычного TTreeView.

Если его объявить непосредственно в модуле с формой - то ну никак не может! :) Если объявить в другом модуле, то это зависит от того, в каком месте ссылка на этот модуль будет в списке uses. Опять таки, зная порядок, по которым IDE ищет юниты - допустить связанную с этим ошибку невозможно.

> А и не надо:

Ну вот. Опять пришли к тому, от чего хотели избавится: замусоривание кода фрагментами, не решающие задачу непосредственно, а занимающиеся управлением графическим интерфейсом.

> Если его объявить непосредственно в модуле с формой - то
> ну никак не может! :)

Разве что, если вы в интерфейсной части юнита с формой B сошлетесь на юнит, в котором находится форма A, что само по себе не рекомендуется.

← →
GeoJ (2007-09-07 15:17) [71]

> [u]У меня из-за него был AV.[/u] AV был в странном месте,
> но после замены извращений на компонент палитры все прекратилось

А у меня есть куча примеров возникновения AV без этого приема, а также куча примеров использования этого приема без появления AV. И что?

А о том, что незнание и/или непонимание зачастую приводит к ошибкам, я и не спорил ;-)

> Инс © (05.07.07 22:05) [35]

> Я утверждаю, что в рамках аккуратного обдуманного использования
> этот способ имеет право на существование.

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

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

Наконец, найдя "ошибку", даже нельзя будет спросить с допустившего ее. Потому что он совершенно справедливо ответит, что никакой ошибки не делал, что если в программе написано TTreeView, то это должно быть именно TTreeView, а не что-то там другое, и что спрашивать надо не с него, а с того, кто ВВЕЛ эту неоднозначность. Это три.

==============

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

Если Вам это занятие нравится - дело Ваше. Но я бы не стал.

О! Противник пустил в ход тяжелую артиллерию! :)

> Юрий Зотов © (07.09.07 15:21) [72]

Все ваши "раз", "два" и "три" имеют место быть, однако они все построены на одном предположении: работа над большим проектом в команде. Это безусловно широкий круг, однако есть случаи, которые в него не включены. Можно привести ограничения, в рамках которых использование данного механизма безопасно - останется достаточно большой круг задач, не противоречащий этим ограничениям. В силу этого, прием имеет право на существование. Следовательно совет "я бы не стал" становится слишком категоричным, нужно смотреть на ситуацию.

> Инс © (07.09.07 15:36) [73]

> они все построены на одном предположении: работа над большим
> проектом в команде.

Нет.

Один человек сделал маленький проект и сдал его заказчику. Через год заказчик попросил что-то изменить/добавить/убавить. Человек изменил/добавил/убавил - а программа вдруг перестала работать.

И теперь бедняга разработчик вот уже полмесяца лазит по программе отладчиком и тщетно пытается понять, почему же TTreeView работает не так, как должен.

Плюс ко всему, повторюсь, что введение Borland-om механизма class helper, который позволяет вполне легально вносить изменения в документированные стандартные классы, рассматриваю как индульгенцию на использование данного механизма в старых версиях Delphi.

> Юрий Зотов © (07.09.07 15:45) [74]

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

> Инс © (07.09.07 15:49) [76]

> Если человек не помнит логики работы своей программы, то он внесет
> ошибку и без использования сего трюка.

Может. Но зачем же увеличивать вероятность ошибки? Зачем заставлять самого себя помнить об этом трюке?

Такие трюки - это бомба замедленного действия, которую человек закладывает сам под себя. Зачем?

Только ради того, чтобы не регистрировать в палитре лишний компонент? А стоит ли овчинка выделки?

Человек переходит оживленную транспортную магистраль НАД подземным переходом. Ему просто лень сначала спускаться, а потом подниматься по лестнице.

Можно? Запросто. При "умелом и аккуратном использовании". Но существует немалая вероятность того, что рано или поздно такой человек свой КАМаз все же встретит.

Зачем?

Инс © (07.09.07 14:35) [69]
> А и не надо:
Ну вот. Опять пришли к тому, от чего хотели избавится: замусоривание кода фрагментами, не решающие задачу непосредственно, а занимающиеся управлением графическим интерфейсом.

Где замусоревание? Одна функция + несколько вызовов ее в FormCreate - замусоривание?

Инс © (07.09.07 14:35) [69]
> В случае TTreeView=class(ComCtrls.TTreeView) можно было
> бы не обращать внимание на неочевидность, он еще и пораждает
> глюки. [u]У меня из-за него был AV.[/u] AV был в странном
> месте, но после замены извращений на компонент палитры все
> прекратилось.

В общем то, это подтверждает лишь уже сказанные неоднократно в данной теме слова о том, что действительно не стоит показывать этот способ тем, кто не понимает что делает.

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

На остальное отвечу, когда потестирую дома.

> Только ради того, чтобы не регистрировать в палитре лишний
> компонент?

Если бы я постоянно так делал (регистрировал компонент в палитре), там бы была по крайней мере одна закладка, имя которой можно смело давать "свалка". Я этого не люблю. Насчет вероятности ошибки - то хотелось бы услышать, на какие грабли я могу наступить, воспользовавшись кодом [3]? Сколько раз уже использовал подобный трюк, и никаких проблем не было, так как о возможных последствиях думаю заранее. Пусть это звучит излишне самоуверенно. Это бомба замедленного действия лишь для того, кто не в состоянии оценить ситуацию.

> Где замусоревание? Одна функция + несколько вызовов ее в
> FormCreate - замусоривание?

Конечно. А где одна - там и две. А где две - там и куча.

> Пока что я не встречал ни одного человека, который бы использовал
> этот прием, понимая что делает.

А я встречал. И даже не одного.

> Инс © (07.09.07 16:20) [79]

> Если бы я постоянно так делал (регистрировал компонент в палитре), там
> бы была по крайней мере одна закладка, имя которой можно смело
> давать "свалка". Я этого не люблю.

Я тоже этого не люблю. Но и помойку в коде я не люблю тоже. Поэтому использую механизм, специально для того и предназначенный. Если какой-то проект требует специфичных компонентов (которые больше нигде использованы не будут), то делается пакет с такими компонентами, а в опциях проекта (но не в дефолтных опциях) прописывается загрузка этого пакета в IDE. Таким образом, ЭТОТ пакет грузится средой (и появляется соответствующая закладка в палитре) ТОЛЬКО вместе с открытием ЭТОГО проекта. А при открытии ДРУГИХ проектов этот пакет НЕ грузится (и закладка, соответственно, НЕ появляется).

И никакой свалки. И никаких трюков.

> хотелось бы услышать, на какие грабли я могу наступить,
> воспользовавшись кодом [3]?

Уже говорилось - неоднозначность класса. Стоит ли повторяться?

> Сколько раз уже использовал подобный трюк, и никаких проблем не было

Надеюсь, Вы и сами понимаете несерьезность подобных "доводов".

> Это бомба замедленного действия лишь для того, кто не в состоянии
> оценить ситуацию.

Сказал один человек - и в этот момент огонек с его сигареты случайно упал в бочку, на которой он сидел...
:о)

> Я тоже этого не люблю. Но и помойку в коде я не люблю тоже.
> Поэтому использую механизм, специально для того и предназначенный.
> Если какой-то проект требует специфичных компонентов (которые
> больше нигде использованы не будут), то делается пакет с
> такими компонентами, а в опциях проекта (но не в дефолтных
> опциях) прописывается загрузка этого пакета в IDE. Таким
> образом, ЭТОТ пакет грузится средой (и появляется соответствующая
> закладка в палитре) ТОЛЬКО вместе с открытием ЭТОГО проекта.
> А при открытии ДРУГИХ проектов этот пакет НЕ грузится (и
> закладка, соответственно, НЕ появляется).
>
> И никакой свалки. И никаких трюков.

Свалка то останется, просто она переместится в другое место - список установленных в среде design-time пакетов. Хотя надо признать, аргумент хороший, подумаю над ним.

> Уже говорилось - неоднозначность класса. Стоит ли повторяться?

Говорилось, но вот только проблемы никакой я не вижу. В данном конкретном случае.

← →
GeoJ (2007-09-07 18:08) [83]

> Где замусоревание? Одна функция + несколько вызовов ее в
> FormCreate - замусоривание?

Не знаю как у кого, но у меня уже FormCreate с многочисленными Create"ами внутри вызывает нервный тик. Какой-то возврат к Паскалю времен Turbo Vision: куча кода который не имеет никакого отношения к логике программы.

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

Встречали. Только не знали либо то, что человек использует этот прием, либо то, что он понимает, что он при этом делает.

По крайней мере, это не первое мое сообщение в данном обсуждении ;-)

to Юрий Зотов:
Возможно, конечно, что я на этом приеме уже руку набил (использую его бог знает сколько лет), но никогда не было проблем с пониманием старого кода. При этом абсолютно неважно, сколько лет назад я его написал. А сейчас вообще с подачи Инса часто выношу видоизмененные компоненты в отдельный юнит с громкоговорящим названием. Да и привычка осталась, прежде, чем начать анализировать модуль формы, посмотреть, не определено ли там что-то перед TForm1.

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

С пакетами вариант, наверное, интересный, но есть одно но: я слишком долго сидел на Delphi-1, а когда перешел на 6-7, то уже не был слишком плотно занят программированием. Так что про пакеты я знаю, но только теоретически. На практике у меня уйдет уйма времени на то, чтобы создать пакет и использовать его. Да еше и на грабли понаступаю (вроде того же ShareMem). Написать же перед TForm1 строчку типа:

TLabel = class(StdCtrls.TLabel)

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

> GeoJ (07.09.07 18:08) [83]

> как, например, это сделано для TForm

И для TForm этого тоже не сделано. Форма в проекте НЕ переопределяет класс TForm, а НАСЛЕДУЕТСЯ от него. Что есть совершенно нормально.

← →
GeoJ (2007-09-09 14:17) [85]

> И для TForm этого тоже не сделано. Форма в проекте НЕ переопределяет
> класс TForm, а НАСЛЕДУЕТСЯ от него. Что есть совершенно
> нормально.

Я это знаю. Я имел в виду, что программист создает новую форму, наследника TForm, нигде ее не регистрирует, но имеет возможность работать с ней в режиме визуального проектирования. Сделают такое же для остальных компонент, не будет нужды в искусственных приемах.

Хотя если уж быть педантом до конца, то в данном приеме речь тоже идет не о переопределении, а о наследовании. Потому что в соответствии с правилами Паскаля, полное имя (чего-либо, в том числе и класса) определяется как имя модуля, за которым следует собственно имя. И такие омонимы встречаются. Пусть и не очень часто. Ну и что? Конкретизируют люди что имеено они имеют в виду, указывая дополнительно имя модуля, и не жужжат.

А что там IDE думает -- это уже ее проблемы. Я программы пишу на Delphi, а не на IDE ;-)

Инс © (07.09.07 16:23) [80]
Конечно. А где одна - там и две. А где две - там и куча.
:)) Откуда у возьмется куча? Чуть добавить коду - получим процедуру замены на всей форме одного класса компонентов на другой. Свалка просто исключена.

GeoJ (07.09.07 18:08) [83]
С пакетами вариант, наверное, интересный, но есть одно но: я слишком долго сидел на Delphi-1, а когда перешел на 6-7, то уже не был слишком плотно занят программированием. Так что про пакеты я знаю, но только теоретически. На практике у меня уйдет уйма времени на то, чтобы создать пакет и использовать его. Да еше и на грабли понаступаю (вроде того же ShareMem).
На создание пакета уходит несколько минут независимо от опыта. А ShareMem тут не причем.
Единственные грабли - необходимость отделения Design-time only пакета в случае специфических редакторов свойств, но тут это не нужно. Это уже выходит за рамки того, что можно сделать вашим приемом.

Инс © (07.09.07 14:35) [69]
В общем то, это подтверждает лишь уже сказанные неоднократно в данной теме слова о том, что действительно не стоит показывать этот способ тем, кто не понимает что делает.

Скажи, как этот прием мог привести к AV? Точнее, я использовал менее продвинутый прием:
TTreeViewChild = class(TTreeView) end; TTreeView = class(TTreeViewChild) end;

P.S. Потестил - Инс оказался прав, что формы из разных юнитов не могут повлиять друг на друга таким образом.

переходим на BDS и юзаем Class Helpers) то, что доктор прописал)

Using Class Helpers
The following code demonstrates the declaration of a class helper:
type TMyClass = class procedure MyProc; function MyFunc: Integer; end; ... procedure TMyClass.MyProc; var X: Integer; begin X := MyFunc; end; function TMyClass.MyFunc: Integer; begin ... end; ... type TMyClassHelper = class helper for TMyClass procedure HelloWorld; function MyFunc: Integer; end; ... procedure TMyClassHelper.HelloWorld; begin writeln(Self.ClassName); // Self refers to TMyClass type, not TMyClassHelper end; function TMyClassHelper.MyFunc: Integer; begin ... end; ... var X: TMyClass; begin X := TMyClass.Create; X.MyProc; // Calls TMyClass.MyProc X.HelloWorld; // Calls TMyClassHelper.HelloWorld X.MyFunc; // Calls TMyClassHelper.MyFunc
Note that the class helper function MyFunc is called, since the class helper takes precedence over the actual class type.

в догонку про замусоривание FormCreate. инициализацию дин.создаваемых компонентов можно произвести в отдельной функции/процедуре, которую соотв.вызвать из FormCreate

← →
jack128_ (2007-09-10 01:45) [89]

> А при открытии ДРУГИХ проектов этот пакет НЕ грузится (и
> закладка, соответственно, НЕ появляется).

Как это работает в ГРУППЕ проэктов? Адекватно?

> переходим на BDS и юзаем Class Helpers) то, что доктор прописал)

ну и реализуй с помощью хелперов [3] ?

← →
GeoJ (2007-09-10 20:22) [90]

> На создание пакета уходит несколько минут независимо от
> опыта

Ну, если минут 30 или 40 -- это несколько, то согласен ;-) Повторюсь, что про пакеты я вообще ничего не знаю. Даже не знаю, какую кнопку надо нажать, чтобы пакет создать. И что с ним потом делать, то же не знаю. Так что придется сначала, как минимум, хелп почитать. А потом кнопки потыкать.

Да мы ж не звери - подскажем последовательность :)

> > переходим на BDS и юзаем Class Helpers) то, что доктор
> прописал)
>
> ну и реализуй с помощью хелперов [3] ?

да, согласен, хелпер видимо тут ниразу не хелпер...

Как подавить реакцию TTreeView на двойной клик? Найти похожие ветки