C# - мега-объектно-ориентированный язык. Настолько ориентированный, что создатели решили насовсем отказаться от глобальных объектов, хотя в классическом ООП на этот счет нет таких строгих правил.

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

Но давайте лучше рассмотрим КАК это выглядит на практике.

Думаю, никто не будет спорить, что в любой программе есть функции, не привязанные к какому-то определенному объекту, т.е. по-сути глобальные (например та же Main()). Так же есть и объекты, не являющиеся членами других объектов, т.е. тоже глобальные. В C# глобальных объектов быть не может, поэтому вышеописанные пасажиры насильно всунуты в классы-обертки, а свою истинную глобальность выдают только наличием волшебного слова "Static".

Но объясните мне, дураку, в чем такое мега-отличие между обычной глобальной переменной от той же переменной с атрибутом static и засунутой в псевдо-класс, который представляет собой просто бесполезную оболочку?

Скажете - это для разделения, чтоб не возникало конфликтов имен? Но чем гениев из мелкософта не удовлетворили обычные (и именно для этого и созданные!) пространства имен? Ну разве это:

namespace MyVariables
{
    int a, b, c;

    void ThisIsMyFunc(string par) {...};
}

namespace MyNamespace
{
    public class МойНафигЗдесьНеНужныйКласс
    {
        public static int a,b,c;

        public static void ThisIsMyFunc(string par) {...};
    }
}

Меня пол-часа бил истерический хохот, когда я впервые увидел вот эту супер-ООП-конструкцию:

static class Program
{
    static void Main(){...}
}

Может в мелкософте ЭТО считают вершиной своих достижений, мне же кажется, что ЭТО - просто чушь.

Символ "Точка с запятой" в языках типа паскаля или Си означает конец команды. Таким образом запись типа:

item += delta; ; ;; ;

является вполне допустимой. В C# такое тоже проходит. Вы можете абсолютно безнаказанно написать например

i = value + 15;; ; value += inkrement; ;;

Компилятор расценит это как само собой разумеющееся и не будет возражать. Но....

Но попробуйте всунуть этот супер-символ после закрывающей фигурной скобки, ограничивающей описание класса или метода и компилятор в истерике разразится отборным матом! Оказывается ТАМ ставить данный символ нельзя!!!

Почему? Спросите об этом дядю Билла.

Задача:

На форме лежит контрол 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;

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

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