Залепа №1. Убогий TreeView.

Задача:

На форме лежит контрол TreeView. В качестве данных используется некий древовидный каталог, пункты которого в дереве будут отображаться так: "[15.06] Подшипники". Тут "15.06" - внутренний код раздела, после которого идет название раздела.

По дереву ползает юзер и может эти данные редактировать. Но изменять он может только название, а вот коды изменять ему нельзя. Т.е. программа должна позволить ему изменять только название.

Первое, что приходит на ум для реализации столь "сложного" поведения - это перехватить моменты начала и завершения редактирования узлов дерева с динамической подменой значений. Т.е. юзер щелкает по узлу, узел переходит в режим редактирования, при этом программа заменяет текст с "[15.06] Подшипники" на "Подшипники". Его-то юзер и изменяет например на "Валенки", затем жмет Enter (конец редактирования) и программа снова заменяет текст узла с "Валенки" на "[15.06] Валенки".

Вроде все просто, благо и события подходящие предусмотрены. Но (как всегда) есть одно "НО"....

Как бы действовала моя программа, работая в НОРМАЛЬНОЙ среде?

Она бы в обработчике TreeView.AfterLabelEdit сначала проверила корректность ввода, а потом аккуратно подменила бы текст "Валенки" на "[15.06] Валенки" и сообщила системе, что все в порядке. В результате пользователь бы получил именно то, что желает. Но, к нашему всеобщему сожалению, этого не происходит.

Проблема в том, что обработчики событий имеют одну малеееееенькую недоработку. А именно, свойство NodeLabelEditEventArgs.Label имеет статус "Read only", т.е. "только-для-чтения".

Давайте подумаем головой. Обработчик события TreeView.AfterLabelEdit предназначен для контроля пользовательского ввода, т.е. после того, как юзер ввел некий текст, наша программа анализирует его на "профпригодность" и выносит вердикт можно ли его допускать для дальнейшей работы или нет. Почему бы не дать возможность программе в этом обработчике не только просигналить пользователю о точ, что введенные данные неверны, но и попытаться самой исправить юзеровские ошибки и нормально продолжить работу?

Но тут мелко-мягкие (в очередной раз) решили, что все программисты в мире - дыбилы и не смогут предусмотреть некую реакцию, исправляющую положение. Именно поэтому они сделали это свойство неизменяемым. Других причин такому поведению я не вижу.

Кстати, финты ушами типа:

TreeNode node = Tree.SelectedNode;
e.Node.EndEdit(false);
node.Text = "[" + it.FromattedCode + "] " + it.name;

тоже не проходят. Остается только тихонько матерясь делать редактирование в отдельном окне.

Вывод: ф топку такой контрол!