Что-то не так с подсчетами. Если изначально код в 10-ричной системе, то в 4 симвоа в 32-ричной эквивалентны 6-и символам в 10-ричной. Другое дело, что 32 десятиричных цифры — слишком много, чтобы кодировать ошибки.
Пока вы используете Join() в потоке UI — ничего работать не будет, т.к. вы ждете завершения работы потока добавления элементов, и на это время поток UI заблокирован.
Рассмотрите использование классов Task и Task вместо Thread. Это более высокоуровневая абстракция для выполнения асинхронных задач, которая, в том числе, поддерживает continuations.
Если чуть точнее — то новый метод просто не относится к определенной выше иерархии наследования. А совпадение имен — это просто случайность, которая не имеет для компилятора какого-то особого смысла. Так что метод мог бы называться DisplayInC(), и в отношении наследования ничего бы не поменялось.
Lachesis хорошая, только вот уже у второй такой мыши — проблемы с нажатием колесика. То надо чуть сильнее надавить после щелчка чтобы сработало, то еще до щелчка когда отпускаешь кнопку — он думает что уже отпустил.
Постоянно нужна, причем из разных областей — и теория графов, и теория вероятностей, и мат. анализ и еще куча областей. Конечно, если писать говносайтики — то ничего не надо (для сайтов с серьезными нагрузками — более чем надо).
Сразу в первых ссылках по запросам «graph planarization» и даже «планаризация графа» — форумы с линками на литературу, статьи, примеры, теорию, опенсорц. библиотеки и т.д.
Если нет виртуальных членов — то тут единственная проблема (впрочем с интерфейсом тоже самое) — подставить своего наследника тому, кто требует базовый класс (интерфейс), но этот наследник не сможет перехватывать вызовы — можно будет только запихать что угодно в конструктор и, допустим по таймеру, что-то с классом делать. Можно, решить это хаком (а вот до .net 4.0 были security аттрибуты, сейчас не могу нагуглить пока замену им).
