Проверка названий пунктов меню - это мощно! Но концептуально ошибочно.
Если нужно решение под сложную задачу, расширяемое и с минимумом лишнего кода и возможных ошибок, то надо не насиловать язык, а плыть в русле его идеологии. Один из вариантов ниже.
Если разнообразие типов узлов мало, то организуешь иерархию классов с общим предком, ну например, TBaseSincObject и методом Sinc с полиморфным поведением. В каждом подклассе инкапсулируешь всю работу по синхронизации представления с моделью данных (парадигма MVC).
Затем при создании узла дерева (пусть оно называется Tree) сохраняешь ссылку на объект Obj нужного подкласса TBaseSincClass:
Код:
var
Obj: TSubSincClass; // Потомок TBaseSincClass
Node: TTreeNode; // Текущий узел дерева
begin
...
Node.Data := Obj;
...
end;
Тогда обработчик события OnChange становится тривиальным и не изменяется при развитии программы:
Код:
procedure TForm1.TreeChange(Sender: TObject; Node: TTreeNode);
begin
(Node.Data as TBaseSincObject).Sinc;
end;
Одна строчка! Всё остальное ушло в полиморфное поведение объектов.
P.S. К слову, полиморфное поведение лучше делать отнюдь не виртуализацией публичного метода (public procedure Sinc; virtual; ). Лучше сделать метод Sinc обычным, а в нём вызвать виртуальный защищённый метод (protected procedure DoSinc; virtual; ).
Простейшая реализация метода Sinc тогда будет выглядеть так:
Код:
procedure TSubSincObject.Sinc;
begin
DoSinc;
end;
Полное обоснование применения этого стандартного шаблона (Nonvirtual interface pattern) писать лень.