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

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

A>>>Открываем 1С, Dynamics NAV, SAP. Всё чего там нет весьма нетипично. Всё что есть не во всех их них — просто нетипично. Так понятнее?
MM>>Хорошо. Там есть TextBox-ы со встроенными кнопками? Наверняка. Я заявляю, что на WPF такое сделать: а) проще, б) получится более гибко.
A>То есть в WPF такого контрола нет. Да, WPF нет контрола и в WinForms нет контрола, но в WPF его нет более приятным способом Весьма трезвый взгляд на вещи.
A>Я тебе открою секрет, обычно покупеается какой-нибудь DXperience, так что набор стандартных контролов не очень-то важен.
Тогда непонятны претензии к сложности смены цвета выделения, ведь "покупеается какой-нибудь DXperience" и т.д. Это неконструктивно. Мы здесь сравниваем не сторонние FW и не говнокодинг в стиле "накидал контролов и всё рулит". Далее, ты пробовал добавлять кастом-редакторы в DevExpress-овские контролы? Придется повозиться в коде. В WPF достаточно задать шаблон в XAML. Это намного проще.

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

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