Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Как подавить реакцию TTreeView на двойной клик? [D7, WinXP]

Страницы: < 1 2 3 4 5 >
АлександрМ © (2007-07-05 01:42:00)
TTreeView при двойном клике сворачивает или разворачивает ту ветку на которой был выполнен этот двойной клик. На событие OnDblClick сделан свой обработчик. И не нужно, чтобы ветка при этом закрывалась или открывалась (пусть пользователь сворачивает или разворачивает её только с помощью кнопок - и +). Подскажите, пожалуйста, как это сделать.

Юрий Зотов (2007-09-07 15:21:00) [21]
> Инс © (05.07.07 22:05) [35]

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

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

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

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

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

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

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

GeoJ (2007-09-07 15:17:00) [22]

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

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

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

Инс (2007-09-07 14:38:00) [23]

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

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

Инс (2007-09-07 14:35:00) [24]

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

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

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

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

> А и не надо:

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

GrayFace (2007-09-07 14:15:00) [25]
Инс © (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;
Писал на ходу, так что за работосособность не ручаюсь, но суть должна быть понятна.

Инс (2007-09-07 10:21:00) [26]

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

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

Германн (2007-09-07 02:10:00) [27]

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

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

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

Германн (2007-09-07 01:12:00) [28]

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

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

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

Shirson (2007-09-06 22:53:00) [29]

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

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

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

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

Lacmus (2007-09-06 12:30:00) [30]
Как все сложно :-)

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

Инс (2007-09-06 12:20:00) [31]

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

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

Инс (2007-09-06 12:18:00) [32]

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

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

Lacmus (2007-09-06 11:55:00) [33]
> Противники использования Инс © (05.07.07 13:29) [3]

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

Инс (2007-09-06 10:46:00) [34]

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

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

Ega23 (2007-09-06 10:38:00) [35]

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

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

Инс (2007-09-06 10:31:00) [36]
Кстати, нашелся еще один аргумент "за" ;-)

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

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

GeoJ (2007-07-10 11:25:00) [37]

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

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

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

Инс (2007-07-10 10:37:00) [38]
Ладно, господа, может завязываем? ;-) А то повторяться уже начали. Обсуждение получилось, есть два взгляда, каждый - обоснован, споряшие стороны что-то из обсуждения вынесут, да и читателям есть пища для ума. Хотя, допускаю, что мой уважаемый тезка (GeoJ) включился в дискуссию чуть позже и ему еще есть что добавить...

Ega23 (2007-07-10 10:25:00) [39]

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

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

GeoJ (2007-07-10 10:23:00) [40]

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

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

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

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

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

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

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

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

Страницы: < 1 2 3 4 5 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »