Здравствуйте, MxMsk, Вы писали:

A>>Есть люди, которые на Си++ пишут в ноутпаде. Я не такой, я себя люблю. У меня, кстати, 2010 SP1, автодополнения нет. Да я не очень крутой спец по WPF и трачу КУЧУ времени на поиск примеров, документации, своего старого кода чтобы понять какими элементами добиться нужной функциональности.
MM>Купи книгу по WPF, и пускай она станет твоим учителем. Подходы WPF отличаются от Windows Forms и на первый взгляд вызывают недоумение. А книги тем и хороши, что разъясняют, почему в дизайне библиотеки принято то или иное решение.

Да причём тут подходы? Дело в конкретной разметке и отсутсвии автодополнения!

A>>Открываем 1С, Dynamics NAV, SAP. Всё чего там нет весьма нетипично. Всё что есть не во всех их них — просто нетипично. Так понятнее?
MM>Хорошо. Там есть TextBox-ы со встроенными кнопками? Наверняка. Я заявляю, что на WPF такое сделать: а) проще, б) получится более гибко.

То есть в WPF такого контрола нет. Да, WPF нет контрола и в WinForms нет контрола, но в WPF его нет более приятным способом Весьма трезвый взгляд на вещи.
Я тебе открою секрет, обычно покупеается какой-нибудь DXperience, так что набор стандартных контролов не очень-то важен.

A>>У бизнес-приложений не бывает простейшего UI.
MM>Ключевое здесь: ты пробовал? Только хочу понять, ты это утверждаешь, проверив реально, или навскидку.

Да, я пробовал. Если бы не пробовал, не говорил бы. Ситуация значительно лучше, если Windows Seven SP1 подключается к Windows Server 2008 R2 SP1. Значительно лучше, но эта конфигурация явно не самая распространённая. Впрочем, шейдерный эфект всё равно всё убивает. А они бывают в строниих контролах. То есть вот знаешь купил библиотеку, постетировал, вроде не глючит и делает то, что надо. Написал приложение, протестировали, всё ОК. А потом выясняется что у клиента все сотрудники работают через терминальные сервисы и всё, приехали. А RemoveFX это вообще MS specific, есть ещё всякие цитриксы древних версий, чтоб им пусто было.

MM>WPF проигрывает Windows Forms в скорости рендеринга, я с этим никогда не спорил. Можно даже поискать здесь ветки, гда обсуждался пефоманс, и я приводил пример, который ставит WPF раком. Вопрос в том, насколько это критично в реальном хорошо спроектированном приложении. О WPF Performance Suite я вообще ничего не знаю. И зачем перерисовывать весь экран

Хороше проектирование тут не при чём. Дело в другом. Вот у тебя есть тулбар сверху основного окна. По какой-то причине (шрифт жлемента стал жирным), этот тулбар стал на 1 пиксель (в случае WPF хватит и 0.1 пикселя) выше. Твоё приложение обладает замечательным резиновым интерфейсом (в WinForms в этим реальная жопа, а я как раз сторонник резиновых интерфейсов)и увеличившийся на 1 пиксель тулбар сдвинул всё содержимое окна на 1 пиксель. В HTML это контроллируется через CSS стиль overflow, надо выставить hidden или scroll. В WinForms резиновость задаётся явно, поэтому если ничего не делать тулбар ничего не сдвинет. А вот в WPF у тебя update region будет размером со всё окно. Например, у тебя есть список элементов и пользователь двигается по нему клавишами со стрелками вверх, вниз. А наверху тулбар (или ещё что-то) на котором элементы меняются в зависимости от выделенного элемента. Достаточно типичная ситуаия. Чуть ошибся в разметке и получаешь дикую просадку производительности.