zub писал(а):остается 2. Что перекрывать в наследниках, чтобы не использовать события onВсякаяХрень. и вообще наверно стоит наследоваться не от TForm?
Переопределить можно наверное TCustomForm.DoClose. Вообще, по традиции, для каждого OnВсякаяХрень в классе (или его предках) есть метод DoВсякаяХрень, который проверяет, назначен ли обработчик и запускает его.
zub писал(а):Что можно почитать чтоб разобраться в логике и назначении методов class`ов LCL?
С такими нетривиальными требованиями могу предложить только исходники LCL
В Lazarus IDE есть куча полезных фич, облегчающих чтение. Если нажать Ctrl и ткнуть мышкой на идентификатор, можно увидеть его декларацию. Так можно посмотреть на что способны стандартные классы и компоненты из RTL, FCL и LCL. Ctrl+Shift+Up/Down -- переход от декларации к реализации и обратно. Ещё поиск по коду, в том числе быстрый (Ctrl+E) и переход вперёд/назад по истории просмотров (есть в меню Поиск, плюс горячие клавиши настраиваются). Именно так я только что нашёл TCustomForm.DoClose.
zub писал(а):4. Стоит ли использовать визуальные возможности лазаря?
программа планируется с минимумом интерфейса, для реализации логики программы (выполнения функций) предусмотрено несколько вариантов, например нажатие кнопки (или нескольких на разных панелях), выбор пункта меню, ввод названия команды в командную строку.
т.е. мои обертки (используемые сейчас, без LCL) кнопок, пунктов меню и т.д. хранят в себе название своих команд и при нажатии-выборе передают их "менеджеру команд" для выполнения. как вписать такую логику в стандартные визуальные компоненты LCL, не погрязнув в разных onСlick для каждой кнопки-пункта меню?
В таком случае ActionList тут имхо не совсем то. По сути, ActionList делает то же самое что у вас уже есть, но обращение к командам там происходит не по строковым именам, а по ссылкам на компоненты. Т.е. каждая команда -- это самостоятельный компонент TAction, с названием, горячей клавишей и (ненавистным
) обработчиком, OnExecute.
В описанном вами случае, я бы посмотрел на другой вариант. Если писать свои компоненты со свойством "команда", для визуального проектирования GUI придётся пересобирать IDE, это действительно не айс. Поэтому можно просто связать уже имеющиеся компоненты с командами. Например:
Код: Выделить всё
TCommandDispatcher = class
private
procedure ButtonClickHandler(Sender: TObject);
procedure XXXHandler(Sender: TObject; XXXParams: TXXXParams);
procedure ExecCommandForComponent(AComponent: TComponent);
public
procedure SetupComponent(AComponent: TComponent; const ACommand: String);
end;
Класс мог бы содержать список соответствий между командами и компонентами. Они могут быть построены как угодно -- (экземпляр компонента;имя команды), (имя компонента;имя команды); (тег копонента, соответсвующий индексу команды в списке) и т.п. Я бы выбрал первый способ, сделал бы его для скорости на TStringList. Т.е. в Strings писал бы имена команд, а в Objects -- экземпляры компонентов.
Тогда SetupComponent добавлял бы такую пару в StringList, и назначал бы компоненту обработчик, уже прописанный в TCommandDispatcher, в зависимости от типа. Т.е.
Код: Выделить всё
if (AComponent is TButton) then
TButton(AComponent).OnClick := Self.ButtonClickHandler; // @ButtonClickHandler для {$mode objfpc}
А ButtonClickHandler для всех кнопок выглядел бы одинаково:
ExecCommandForComponent, в свою очередь, искала бы в списке команду для данного экземпляра компонента и передавала бы её на исполнение менеджеру команд.
Тогда в результате получим один класс-диспетчер, который содержит по одному обработчику на нескольких типов компонентов, и код инициализации формы в виде множества вызовов типа:
Код: Выделить всё
CommandDispatcher.SetupComponent(btnUpdateView, 'update_view_cmd');
zub писал(а):Еще меня мучает вопросик - где для формы производить инициализацию дочерних контролов? в конструкторе или в AfterConstruction?
Имхо лучше в AfterConstruction, в конструкторе Handle может быть ещё не выделен. Да вообщем то и за AfterConstruction не ручаюсь, лучше смотреть в исходниках.
Добавлено спустя 5 минут 28 секунд:Re: Вопросы по LCLИз плюсов дизайнера -- предварительный просмотр, и ещё там немного быстрее устанавливать привязки компонентов друг к другу, чем через код. Если я правильно понимаю, единственная причина по которой может понадобиться переписывать программу на Pascal с WinAPI на LCL -- это кроссплатформенность. А поскольку DPI, размеры шрифтов и элементов GUI на разных ОС разные, то без "резинового" GUI не обойтись. Для начальных сведений можно посмотреть
http://freepascal.ru/article//lazarus/20090217210602/ , дальше --
http://wiki.lazarus.freepascal.org/Autosize_/_Layout
