| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Как подавить реакцию TTreeView на двойной клик? [D7, WinXP]
АлександрМ © (2007-07-05 01:42:00)TTreeView при двойном клике сворачивает или разворачивает ту ветку на которой был выполнен этот двойной клик. На событие OnDblClick сделан свой обработчик. И не нужно, чтобы ветка при этом закрывалась или открывалась (пусть пользователь сворачивает или разворачивает её только с помощью кнопок - и +). Подскажите, пожалуйста, как это сделать.
MetalFan (2007-09-11 23:22:00) [1]
> > переходим на BDS и юзаем Class Helpers) то, что доктор
> прописал)
>
> ну и реализуй с помощью хелперов [3] ?
да, согласен, хелпер видимо тут ниразу не хелпер...
GrayFace (2007-09-11 23:02:00) [2]Да мы ж не звери - подскажем последовательность :)
GeoJ (2007-09-10 20:22:00) [3]
> На создание пакета уходит несколько минут независимо от
> опыта
Ну, если минут 30 или 40 -- это несколько, то согласен ;-) Повторюсь, что про пакеты я вообще ничего не знаю. Даже не знаю, какую кнопку надо нажать, чтобы пакет создать. И что с ним потом делать, то же не знаю. Так что придется сначала, как минимум, хелп почитать. А потом кнопки потыкать.
jack128_ (2007-09-10 01:45:00) [4]
> А при открытии ДРУГИХ проектов этот пакет НЕ грузится (и
> закладка, соответственно, НЕ появляется).
Как это работает в ГРУППЕ проэктов? Адекватно?
> переходим на BDS и юзаем Class Helpers) то, что доктор прописал)
ну и реализуй с помощью хелперов [3] ?
MetalFan (2007-09-09 21:05:00) [5]в догонку про замусоривание FormCreate. инициализацию дин.создаваемых компонентов можно произвести в отдельной функции/процедуре, которую соотв.вызвать из FormCreate
MetalFan (2007-09-09 21:03:00) [6]переходим на 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.
GrayFace (2007-09-09 20:40:00) [7]Инс © (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. Потестил - Инс оказался прав, что формы из разных юнитов не могут повлиять друг на друга таким образом.
GeoJ (2007-09-09 14:17:00) [8]
> И для TForm этого тоже не сделано. Форма в проекте НЕ переопределяет
> класс TForm, а НАСЛЕДУЕТСЯ от него. Что есть совершенно
> нормально.
Я это знаю. Я имел в виду, что программист создает новую форму, наследника TForm, нигде ее не регистрирует, но имеет возможность работать с ней в режиме визуального проектирования. Сделают такое же для остальных компонент, не будет нужды в искусственных приемах.
Хотя если уж быть педантом до конца, то в данном приеме речь тоже идет не о переопределении, а о наследовании. Потому что в соответствии с правилами Паскаля, полное имя (чего-либо, в том числе и класса) определяется как имя модуля, за которым следует собственно имя. И такие омонимы встречаются. Пусть и не очень часто. Ну и что? Конкретизируют люди что имеено они имеют в виду, указывая дополнительно имя модуля, и не жужжат.
А что там IDE думает -- это уже ее проблемы. Я программы пишу на Delphi, а не на IDE ;-)
Юрий Зотов (2007-09-07 18:14:00) [9]> GeoJ (07.09.07 18:08) [83]
> как, например, это сделано для TForm
И для TForm этого тоже не сделано. Форма в проекте НЕ переопределяет класс TForm, а НАСЛЕДУЕТСЯ от него. Что есть совершенно нормально.
GeoJ (2007-09-07 18:08:00) [10]
> Где замусоревание? Одна функция + несколько вызовов ее в
> FormCreate - замусоривание?
Не знаю как у кого, но у меня уже FormCreate с многочисленными Create'ами внутри вызывает нервный тик. Какой-то возврат к Паскалю времен Turbo Vision: куча кода который не имеет никакого отношения к логике программы.
> Пока что я не встречал ни одного человека, который бы использовал
> этот прием, понимая что делает
Встречали. Только не знали либо то, что человек использует этот прием, либо то, что он понимает, что он при этом делает.
По крайней мере, это не первое мое сообщение в данном обсуждении ;-)
to Юрий Зотов:
Возможно, конечно, что я на этом приеме уже руку набил (использую его бог знает сколько лет), но никогда не было проблем с пониманием старого кода. При этом абсолютно неважно, сколько лет назад я его написал. А сейчас вообще с подачи Инса часто выношу видоизмененные компоненты в отдельный юнит с громкоговорящим названием. Да и привычка осталась, прежде, чем начать анализировать модуль формы, посмотреть, не определено ли там что-то перед TForm1.
В принципе, согласен, что этот прием "от бедности". Если бы в среде был предусмотрен законный механизм модификации компонент (как, например, это сделано для TForm), то я с радостью бы стал им пользоваться.
С пакетами вариант, наверное, интересный, но есть одно но: я слишком долго сидел на Delphi-1, а когда перешел на 6-7, то уже не был слишком плотно занят программированием. Так что про пакеты я знаю, но только теоретически. На практике у меня уйдет уйма времени на то, чтобы создать пакет и использовать его. Да еше и на грабли понаступаю (вроде того же ShareMem). Написать же перед TForm1 строчку типа:
TLabel = class(StdCtrls.TLabel)
и переопределить какой-нибудь один нужный мне метод делается в режиме реального времени.
Инс (2007-09-07 17:20:00) [11]
> Я тоже этого не люблю. Но и помойку в коде я не люблю тоже.
> Поэтому использую механизм, специально для того и предназначенный.
> Если какой-то проект требует специфичных компонентов (которые
> больше нигде использованы не будут), то делается пакет с
> такими компонентами, а в опциях проекта (но не в дефолтных
> опциях) прописывается загрузка этого пакета в IDE. Таким
> образом, ЭТОТ пакет грузится средой (и появляется соответствующая
> закладка в палитре) ТОЛЬКО вместе с открытием ЭТОГО проекта.
> А при открытии ДРУГИХ проектов этот пакет НЕ грузится (и
> закладка, соответственно, НЕ появляется).
>
> И никакой свалки. И никаких трюков.
Свалка то останется, просто она переместится в другое место - список установленных в среде design-time пакетов. Хотя надо признать, аргумент хороший, подумаю над ним.
> Уже говорилось - неоднозначность класса. Стоит ли повторяться?
Говорилось, но вот только проблемы никакой я не вижу. В данном конкретном случае.
Юрий Зотов (2007-09-07 16:59:00) [12]> Инс © (07.09.07 16:20) [79]
> Если бы я постоянно так делал (регистрировал компонент в палитре), там
> бы была по крайней мере одна закладка, имя которой можно смело
> давать "свалка". Я этого не люблю.
Я тоже этого не люблю. Но и помойку в коде я не люблю тоже. Поэтому использую механизм, специально для того и предназначенный. Если какой-то проект требует специфичных компонентов (которые больше нигде использованы не будут), то делается пакет с такими компонентами, а в опциях проекта (но не в дефолтных опциях) прописывается загрузка этого пакета в IDE. Таким образом, ЭТОТ пакет грузится средой (и появляется соответствующая закладка в палитре) ТОЛЬКО вместе с открытием ЭТОГО проекта. А при открытии ДРУГИХ проектов этот пакет НЕ грузится (и закладка, соответственно, НЕ появляется).
И никакой свалки. И никаких трюков.
> хотелось бы услышать, на какие грабли я могу наступить,
> воспользовавшись кодом [3]?
Уже говорилось - неоднозначность класса. Стоит ли повторяться?
> Сколько раз уже использовал подобный трюк, и никаких проблем не было
Надеюсь, Вы и сами понимаете несерьезность подобных "доводов".
> Это бомба замедленного действия лишь для того, кто не в состоянии
> оценить ситуацию.
Сказал один человек - и в этот момент огонек с его сигареты случайно упал в бочку, на которой он сидел...
:о)
Инс (2007-09-07 16:23:00) [13]
> Где замусоревание? Одна функция + несколько вызовов ее в
> FormCreate - замусоривание?
Конечно. А где одна - там и две. А где две - там и куча.
> Пока что я не встречал ни одного человека, который бы использовал
> этот прием, понимая что делает.
А я встречал. И даже не одного.
Инс (2007-09-07 16:20:00) [14]
> Только ради того, чтобы не регистрировать в палитре лишний
> компонент?
Если бы я постоянно так делал (регистрировал компонент в палитре), там бы была по крайней мере одна закладка, имя которой можно смело давать "свалка". Я этого не люблю. Насчет вероятности ошибки - то хотелось бы услышать, на какие грабли я могу наступить, воспользовавшись кодом [3]? Сколько раз уже использовал подобный трюк, и никаких проблем не было, так как о возможных последствиях думаю заранее. Пусть это звучит излишне самоуверенно. Это бомба замедленного действия лишь для того, кто не в состоянии оценить ситуацию.
GrayFace (2007-09-07 16:15:00) [15]Инс © (07.09.07 14:35) [69]
> А и не надо:
Ну вот. Опять пришли к тому, от чего хотели избавится: замусоривание кода фрагментами, не решающие задачу непосредственно, а занимающиеся управлением графическим интерфейсом.
Где замусоревание? Одна функция + несколько вызовов ее в FormCreate - замусоривание?
Инс © (07.09.07 14:35) [69]
> В случае TTreeView=class(ComCtrls.TTreeView) можно было
> бы не обращать внимание на неочевидность, он еще и пораждает
> глюки. [u]У меня из-за него был AV.[/u] AV был в странном
> месте, но после замены извращений на компонент палитры все
> прекратилось.
В общем то, это подтверждает лишь уже сказанные неоднократно в данной теме слова о том, что действительно не стоит показывать этот способ тем, кто не понимает что делает.
Пока что я не встречал ни одного человека, который бы использовал этот прием, понимая что делает.
На остальное отвечу, когда потестирую дома.
Юрий Зотов (2007-09-07 16:06:00) [16]> Инс © (07.09.07 15:49) [76]
> Если человек не помнит логики работы своей программы, то он внесет
> ошибку и без использования сего трюка.
Может. Но зачем же увеличивать вероятность ошибки? Зачем заставлять самого себя помнить об этом трюке?
Такие трюки - это бомба замедленного действия, которую человек закладывает сам под себя. Зачем?
Только ради того, чтобы не регистрировать в палитре лишний компонент? А стоит ли овчинка выделки?
Человек переходит оживленную транспортную магистраль НАД подземным переходом. Ему просто лень сначала спускаться, а потом подниматься по лестнице.
Можно? Запросто. При "умелом и аккуратном использовании". Но существует немалая вероятность того, что рано или поздно такой человек свой КАМаз все же встретит.
Зачем?
Инс (2007-09-07 15:49:00) [17]
> Юрий Зотов © (07.09.07 15:45) [74]
Ну это уж слишком надуманная ситуация. Если человек не помнит логики работы своей программы, то он внесет ошибку и без использования сего трюка.
Инс (2007-09-07 15:46:00) [18]Плюс ко всему, повторюсь, что введение Borland-om механизма class helper, который позволяет вполне легально вносить изменения в документированные стандартные классы, рассматриваю как индульгенцию на использование данного механизма в старых версиях Delphi.
Юрий Зотов (2007-09-07 15:45:00) [19]> Инс © (07.09.07 15:36) [73]
> они все построены на одном предположении: работа над большим
> проектом в команде.
Нет.
Одинчеловек сделал маленькийпроект и сдал его заказчику. Через год заказчик попросил что-то изменить/добавить/убавить. Человек изменил/добавил/убавил - а программа вдруг перестала работать.
И теперь бедняга разработчик вот уже полмесяца лазит по программе отладчиком и тщетно пытается понять, почему же TTreeView работает не так, как должен.
Инс (2007-09-07 15:36:00) [20]О! Противник пустил в ход тяжелую артиллерию! :)
> Юрий Зотов © (07.09.07 15:21) [72]
Все ваши "раз", "два" и "три" имеют место быть, однако они все построены на одном предположении: работа над большим проектом в команде. Это безусловно широкий круг, однако есть случаи, которые в него не включены. Можно привести ограничения, в рамках которых использование данного механизма безопасно - останется достаточно большой круг задач, не противоречащий этим ограничениям. В силу этого, прием имеет право на существование. Следовательно совет "я бы не стал" становится слишком категоричным, нужно смотреть на ситуацию.
| |
Страницы: 