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

← →
Инс © (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 можно использовать как ручную гранату контактного действия. > Надо всего лишь перед броском об что-нибудь твёрдое её ударить, чтобы на боевой взвод встала.
> Прямых запретов нигде нет. Однако почему-то её таким образом крайне редко используют. Вот интересно, а почему?
>

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

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

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

← →
Германн © (2007-09-07 01:12) [65]

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

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

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

← →
Германн © (2007-09-07 02:10) [66]

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

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

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

← →
Инс © (2007-09-07 10:21) [67]

> Германн © (07.09.07 02:10) [66]

Это же из Архангельского? Точнее из статьи, про то, как его любят. Угадал?

← →
GrayFace © (2007-09-07 14:15) [68]

Инс © (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 - замусоривание?

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

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

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

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