Здравствуйте, evo, Вы писали:
A>>А можно английский текст? Я там просто не смог найти даже вопрос. evo>http://joshsmithonwpf.wordpress.com/2007/09/05/wpf-vs-windows-forms/ evo>Извините, непонятно написал. Я имел ввиду ту ссылку что вы привели. Два последних сообщения в самом низу (вопрос-ответ).
Ну во-первых, его спросили не вообще, а про "RIA apps delivered over the internet", а во вторых он ответил что лучше Silverlight использовать.
Я забыл про ещё один момент. Поддержки локализации интерфейсов в WPF прокатически нет. То есть как в WinForms, переключить язык прямо в дизайнере и внести изменения просто нельзя. Вот тут подробнее http://msdn.microsoft.com/en-us/library/ms746621.aspx
Я знаю, некоторые скажут что это типа правильно отдавать переводчику текстовый файл, а не заставлять его работать в дизайнере VS. Но, его и так никтон е заставлял работать в дизайнере VS, а те кто хоть раз отдавал переводчику просто текстовый файл, знают что не видя контекста использования выражений переводчик выдаёт крайне низкокачественный результат. Элементарно, многие английские слова могут переводится на русский язык как существительное или глагол. Ну и падеж по текстовому файлу тоже не угадаешь.
Здравствуйте, henson, Вы писали:
H>Раз уж товарисч adontz решил поупрямиться отвечу развернуто. H>Бизнес приложения как раз лучше писать на WPF т.к. элементарно получается быстрей и удобней в разработке, выглядит современно, легче модифицировать и идеологически более правильно.
С тех пор как в WPF починили анти-алиансинг я в большинстве "типичных бизнес-приложений" по внешнему виду совершенно не различаю написаны они на винформс или WPF. Ибо грид с россыпью текстобоксов выглядит абсолютно одинаково и там, и там.
Здравствуйте, adontz, Вы писали:
A>Я знаю, некоторые скажут что это типа правильно отдавать переводчику текстовый файл, а не заставлять его работать в дизайнере VS. Но, его и так никтон е заставлял работать в дизайнере VS, а те кто хоть раз отдавал переводчику просто текстовый файл, знают что не видя контекста использования выражений переводчик выдаёт крайне низкокачественный результат. Элементарно, многие английские слова могут переводится на русский язык как существительное или глагол. Ну и падеж по текстовому файлу тоже не угадаешь.
Тем не менее многие конторы, которые работали с переводами, просто просили ресурсные файлики.
Здравствуйте, evo, Вы писали:
evo>Как вы считаете, если сейчас начал изучать .NET и C# стоит ли учить winforms или сразу переходить к WPF. Немножко пробовал winforms и на первый взгляд все просто и логично. С WPF почти не знаком. Читал, что учить значительно труднее. Сложно сделать выбор, когда так мало знаешь. Гуглил этот вопрос и однозначного ответа не нашел. Лично мне было бы интереснее начать с WPF, но не хочется, чтоб получилось так, что много где еще нужны winforms, а я не буду их знать.
WinForms очень прост. Если не писать уж совсем изощренный UI, то и учить там можно сказать практически нечего. MSDN дает ответы на все вопросы буквально на ходу. Конечно же, если знать на память все свойства и методы контролов, то можно лепить UI быстрее и что немаловажно, качественнее. Но тут уже как раз стоит обратить свое внимание на WPF — вот его стоит учить по-настоящему.
Здравствуйте, evo, Вы писали:
evo>Как вы считаете, если сейчас начал изучать .NET и C# стоит ли учить winforms или сразу переходить к WPF. Немножко пробовал winforms и на первый взгляд все просто и логично. С WPF почти не знаком. Читал, что учить значительно труднее. Сложно сделать выбор, когда так мало знаешь. Гуглил этот вопрос и однозначного ответа не нашел. Лично мне было бы интереснее начать с WPF, но не хочется, чтоб получилось так, что много где еще нужны winforms, а я не буду их знать.
Здравствуйте, adontz, Вы писали:
H>>Раз уж товарисч adontz решил поупрямиться отвечу развернуто. H>>Бизнес приложения как раз лучше писать на WPF т.к. элементарно получается быстрей и удобней в разработке A>Это не правда. Если сравнивать скорость работы, то XAML редактор оставляет желать лучшего.
Нет, это правда, как ни удивительно. Визуальный редактор WPF — отстой, но в самом XAML писать оказывается гораздо проще и продуктивнее. Я по первости тоже считал, что это будет ужасно, оказалось всё наоборот. Если, скажем, в Windows Forms для переноса контролов выровненных по краям и закрывающих друг друга тебе нужно изловчиться, чтобы выделить их, то в XAML это простое выделение абзаца. Перенос компонентов — простое копирование/перемещение текста. Нереально удобно. И этот отмечали многие, плотно поработав с WPF некоторое время.
H>>легче модифицировать A>Легче модифицировать что?
Визуальщину. Возможности гораздо богаче. Элементарная задача: захотел заказчик ListBox с элементами по горизонтали, или добавить ComboBox в TreeView. У нас такое было! Как думаешь, сколько у тебя уйдет времени на такое в Windows Forms? А на WPF это час работы, где возня с контролами вообще пять минут.
H>>Если нужна скорость или компьютер не тянет WPF, то используется текстовый терминал как при регистрации в аэропорту, но это скорей промышленный use case нежели типичный бизнес. A>Текстовый терминал? Это шутка? Если уж что-то и применяется помимо компьютера, так это тонкие клиенты для терсиналной сессии. На них Linux или Widnows XP. Уж точно не Seven SP1, да и сервер не 2008 R2 SP1. Как работает WPF завязанный на аппаратное ускорение в терминальной сессии? Как говно!
Пробовал? У нас демонстрация проходит в терминальной сессии. Сам боялся, что будет просто ужас. Но нет, скорость получилась хорошая, никто не говорит "а че так медленно".
Здравствуйте, MxMsk, Вы писали:
MM>Нет, это правда, как ни удивительно. Визуальный редактор WPF — отстой, но в самом XAML писать оказывается гораздо проще и продуктивнее. Я по первости тоже считал, что это будет ужасно, оказалось всё наоборот. Если, скажем, в Windows Forms для переноса контролов выровненных по краям и закрывающих друг друга тебе нужно изловчиться, чтобы выделить их, то в XAML это простое выделение абзаца. Перенос компонентов — простое копирование/перемещение текста. Нереально удобно. И этот отмечали многие, плотно поработав с WPF некоторое время.
У редактора XAML проблемы с автодополнением, не говоря уже о том что он регулярно подвисает на 1-2 секунды. Я не вижу что тут можно обсуждать.
A>>Легче модифицировать что? MM>Визуальщину. Возможности гораздо богаче. Элементарная задача: захотел заказчик ListBox с элементами по горизонтали, или добавить ComboBox в TreeView. У нас такое было! Как думаешь, сколько у тебя уйдет времени на такое в Windows Forms? А на WPF это час работы, где возня с контролами вообще пять минут.
А если тебя попросят поменять цвета выделения: фона и тестка? О-па, во всемогущем WPF цвета выделения прибиты гвоздями, а на WinForms это задача на пять минут. Я не думаю, что меряться решением нетипичных задач плодотворное занятие.
A>>Текстовый терминал? Это шутка? Если уж что-то и применяется помимо компьютера, так это тонкие клиенты для терсиналной сессии. На них Linux или Widnows XP. Уж точно не Seven SP1, да и сервер не 2008 R2 SP1. Как работает WPF завязанный на аппаратное ускорение в терминальной сессии? Как говно! MM>Пробовал? У нас демонстрация проходит в терминальной сессии. Сам боялся, что будет просто ужас. Но нет, скорость получилась хорошая, никто не говорит "а че так медленно".
Причём тут домонстрация? Ты видел терминалки на которых одновременно сотня пользователей? Я — да. Никто и не говорил что всё будет тормозить в одной сессии, речь о продкашене.
Здравствуйте, adontz, Вы писали:
MM>>Нет, это правда, как ни удивительно. Визуальный редактор WPF — отстой, но в самом XAML писать оказывается гораздо проще и продуктивнее. Я по первости тоже считал, что это будет ужасно, оказалось всё наоборот. Если, скажем, в Windows Forms для переноса контролов выровненных по краям и закрывающих друг друга тебе нужно изловчиться, чтобы выделить их, то в XAML это простое выделение абзаца. Перенос компонентов — простое копирование/перемещение текста. Нереально удобно. И этот отмечали многие, плотно поработав с WPF некоторое время. A>У редактора XAML проблемы с автодополнением, не говоря уже о том что он регулярно подвисает на 1-2 секунды. Я не вижу что тут можно обсуждать.
В 2008-й Студии вообще не было толкового intellisense, и тем не менее, редактирование XAML-а все-равно оказывалось удобнее. Этим просто надо реально заниматься, осваивать технику, так сказать.
A>А если тебя попросят поменять цвета выделения: фона и тестка? О-па, во всемогущем WPF цвета выделения прибиты гвоздями, а на WinForms это задача на пять минут. Я не думаю, что меряться решением нетипичных задач плодотворное занятие.
Угу. Как обычно: всё, что на Windows Forms делается сложно — это всё "нетипично". А на WPF даже "прибитые гвоздями" (кстати, не всегда) цвета выделения меняются за пять минут.
A>>>Текстовый терминал? Это шутка? Если уж что-то и применяется помимо компьютера, так это тонкие клиенты для терсиналной сессии. На них Linux или Widnows XP. Уж точно не Seven SP1, да и сервер не 2008 R2 SP1. Как работает WPF завязанный на аппаратное ускорение в терминальной сессии? Как говно! MM>>Пробовал? У нас демонстрация проходит в терминальной сессии. Сам боялся, что будет просто ужас. Но нет, скорость получилась хорошая, никто не говорит "а че так медленно". A>Причём тут домонстрация? Ты видел терминалки на которых одновременно сотня пользователей? Я — да. Никто и не говорил что всё будет тормозить в одной сессии, речь о продкашене.
Если ты пробовал с простейшим UI на WPF и были дикие тормоза, то ок.
Здравствуйте, MxMsk, Вы писали:
A>>У редактора XAML проблемы с автодополнением, не говоря уже о том что он регулярно подвисает на 1-2 секунды. Я не вижу что тут можно обсуждать. MM>В 2008-й Студии вообще не было толкового intellisense, и тем не менее, редактирование XAML-а все-равно оказывалось удобнее. Этим просто надо реально заниматься, осваивать технику, так сказать.
Есть люди, которые на Си++ пишут в ноутпаде. Я не такой, я себя люблю. У меня, кстати, 2010 SP1, автодополнения нет. Да я не очень крутой спец по WPF и трачу КУЧУ времени на поиск примеров, документации, своего старого кода чтобы понять какими элементами добиться нужной функциональности.
A>>А если тебя попросят поменять цвета выделения: фона и тестка? О-па, во всемогущем WPF цвета выделения прибиты гвоздями, а на WinForms это задача на пять минут. Я не думаю, что меряться решением нетипичных задач плодотворное занятие. MM>Угу. Как обычно: всё, что на Windows Forms делается сложно — это всё "нетипично". А на WPF даже "прибитые гвоздями" (кстати, не всегда) цвета выделения меняются за пять минут.
Открываем 1С, Dynamics NAV, SAP. Всё чего там нет весьма нетипично. Всё что есть не во всех их них — просто нетипично. Так понятнее?
A>>Причём тут домонстрация? Ты видел терминалки на которых одновременно сотня пользователей? Я — да. Никто и не говорил что всё будет тормозить в одной сессии, речь о продкашене. MM>Если ты пробовал с простейшим UI на WPF и были дикие тормоза, то ок.
У бизнес-приложений не бывает простейшего UI.
Вообще, когда мы говорим о скорости WPF, подумай вот о чём. Есть куча Widget Library: GTK, wxWidgets, Windows Controls (WinForms обёртка), Qt, HTMLayout, и.т.д. Из всех фреймворков только WPF использует аппартное ускорение по полной. Остальные оптимизируют blit/blend. HTMLayout что-то делает через Direct2D, но DirectX, тем более DirectX 9 не использует больше ни одна библиотека. Справедливости ради, приличных OpenGL based библиотек я тоже не видел. Я могу что-то упустить, но вопрос построения UI для меня важен и я регулярно если не пишу пробный проект, то хотя бы ознакомляюсь по документации. И вот, в WPF, этой крутой библиотеке с самым продвинутым аппаратным ускорением (шейдерными эффектами, етить) есть популярный (часто описываемый в блогах и т.д.) инструмент WPF Performance Suite, который показывает тебе update regions. То есть на доморощеном WinForms перерисовать весь экран не было проблемой, а на супер-крутом WPF — ещё как! Microsoft не выпустили Mole, хотя инструмент нужный и популярный, многие без него как без рук, а вот выделить ресурсы Performance Suite они посчитали правильным. Тебе не кажется, что такое чистосердечное признание заслуживает пристального внимания?
Здравствуйте, adontz, Вы писали:
A>Есть люди, которые на Си++ пишут в ноутпаде. Я не такой, я себя люблю. У меня, кстати, 2010 SP1, автодополнения нет. Да я не очень крутой спец по WPF и трачу КУЧУ времени на поиск примеров, документации, своего старого кода чтобы понять какими элементами добиться нужной функциональности.
Купи книгу по WPF, и пускай она станет твоим учителем. Подходы WPF отличаются от Windows Forms и на первый взгляд вызывают недоумение. А книги тем и хороши, что разъясняют, почему в дизайне библиотеки принято то или иное решение.
MM>>Угу. Как обычно: всё, что на Windows Forms делается сложно — это всё "нетипично". А на WPF даже "прибитые гвоздями" (кстати, не всегда) цвета выделения меняются за пять минут. A>Открываем 1С, Dynamics NAV, SAP. Всё чего там нет весьма нетипично. Всё что есть не во всех их них — просто нетипично. Так понятнее?
Хорошо. Там есть TextBox-ы со встроенными кнопками? Наверняка. Я заявляю, что на WPF такое сделать: а) проще, б) получится более гибко.
MM>>Если ты пробовал с простейшим UI на WPF и были дикие тормоза, то ок. A>У бизнес-приложений не бывает простейшего UI.
Ключевое здесь: ты пробовал? Только хочу понять, ты это утверждаешь, проверив реально, или навскидку.
A>Вообще, когда мы говорим о скорости WPF, подумай вот о чём. Есть куча Widget Library: GTK, wxWidgets, Windows Controls (WinForms обёртка), Qt, HTMLayout, и.т.д. Из всех фреймворков только WPF использует аппартное ускорение по полной. Остальные оптимизируют blit/blend. HTMLayout что-то делает через Direct2D, но DirectX, тем более DirectX 9 не использует больше ни одна библиотека. Справедливости ради, приличных OpenGL based библиотек я тоже не видел. Я могу что-то упустить, но вопрос построения UI для меня важен и я регулярно если не пишу пробный проект, то хотя бы ознакомляюсь по документации. И вот, в WPF, этой крутой библиотеке с самым продвинутым аппаратным ускорением (шейдерными эффектами, етить) есть популярный (часто описываемый в блогах и т.д.) инструмент WPF Performance Suite, который показывает тебе update regions. То есть на доморощеном WinForms перерисовать весь экран не было проблемой, а на супер-крутом WPF — ещё как! Microsoft не выпустили Mole, хотя инструмент нужный и популярный, многие без него как без рук, а вот выделить ресурсы Performance Suite они посчитали правильным. Тебе не кажется, что такое чистосердечное признание заслуживает пристального внимания?
WPF проигрывает Windows Forms в скорости рендеринга, я с этим никогда не спорил. Можно даже поискать здесь ветки, гда обсуждался пефоманс, и я приводил пример, который ставит WPF раком. Вопрос в том, насколько это критично в реальном хорошо спроектированном приложении. О WPF Performance Suite я вообще ничего не знаю. И зачем перерисовывать весь экран
Здравствуйте, 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 будет размером со всё окно. Например, у тебя есть список элементов и пользователь двигается по нему клавишами со стрелками вверх, вниз. А наверху тулбар (или ещё что-то) на котором элементы меняются в зависимости от выделенного элемента. Достаточно типичная ситуаия. Чуть ошибся в разметке и получаешь дикую просадку производительности.
Здравствуйте, adontz, Вы писали:
A>Ну во-первых, его спросили не вообще, а про "RIA apps delivered over the internet", а во вторых он ответил что лучше Silverlight использовать.
Да лопухнулся я. Просто как увидел, что спрашивают:
«So, what would you suggest if we’re just now transitioning over to .NET?»
Потом ответ:
«I would definitely head for WPF.»
Сразу добавил сюда сообщение.
Здравствуйте, 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 будет размером со всё окно. Например, у тебя есть список элементов и пользователь двигается по нему клавишами со стрелками вверх, вниз. А наверху тулбар (или ещё что-то) на котором элементы меняются в зависимости от выделенного элемента. Достаточно типичная ситуаия. Чуть ошибся в разметке и получаешь дикую просадку производительности.
Если тулбар требует сдвига элементов, то в любой технологии это потребует перерисовки всего, что под ним.
Здравствуйте, MxMsk, Вы писали:
MM>Тогда непонятны претензии к сложности смены цвета выделения
У меня нет претензий, я лишь показал что во всех библиотеках есть трудно/неочевидно решаемые нестандартные задачи.
MM>Хорошо. Пришли к тому, что в WPF плоховато с обратной совместимостью. Меня это устраивает.
Тут принципиальная проблема, а не просто с обратной совместимостью. Библиотека основанная на DirectX, в отличие, кстати, от Direct2D, всегда в терминальной сессии будет работать значительно хуже. Это при том что Direct2D умеет использовать DirectX 10.1, но, в отличие от WPF, не умеет использовать WARP10.
Обратная совместимость неправильный термин, тут проблемы с прямой совместимостью. RemoteFX позволил прокидывать через RDP всякие полупрозрачности, но это, во-первых, всего ли одна из технологий, а во-вторых, полупрозрачности не покрывают сложность рендеринга WPF. Трафик стал меньше, время отклика уменьшилось, это да. Но вот нагрузка на процессор от RemoteFX не уменьшилась.
MM>Если тулбар требует сдвига элементов, то в любой технологии это потребует перерисовки всего, что под ним.
Нет. Например, HTMLayout (называю его, потому что больше знаю именно о его внутреностях, наверняка проблема решена и в других библиотеках) будет использовать аппаратный скролл видеокарты. Фактический update region будет только тулбар. Что творится внутри WinForms не знаю, но наличие функции ScrollWindow и кое-какие наблюдения позволяют радоваться за олдскул. Прокрутка области экрана — операция имевшая аппаратную поддержку ещё десять лет тому назад. А WPF, да, ты прав, перерисует весь экран.
Здравствуйте, objMihail, Вы писали:
M>Сравнивать статистику снятую летом в период отпусков и зимой это как-то, мягко говоря, некультурно.
Вообще, сравнение показателей не было основной целью. Основной целью было просто одномоментное получение картинки что и как часто востребовано.
Но все равно, объясните пожалуйста почему "некультурно"?
Здравствуйте, MozgC, Вы писали:
MC>Вообще, сравнение показателей не было основной целью. Основной целью было просто одномоментное получение картинки что и как часто востребовано.
Тогда зачем эти сдвоенные столбики? Именно для сравнения это делалось.
MC>Но все равно, объясните пожалуйста почему "некультурно"?
Ну как бы если для сравнения, то объясняю — создаётся впечатление, что в течении этих ~6 месяцев почти по всем вакансиям C#/Net наблюдается рост, а это на самом деле всего лишь сезонный рост... Как-то так. Это наверное не касается сравнения WinForms и WPF, т.к. видно, что они поменялись местами фактически. Но и это, в принципе, может обуславливаться сезонными особенностями
Здравствуйте, objMihail, Вы писали:
M>Ну как бы если для сравнения, то объясняю — создаётся впечатление, что в течении этих ~6 месяцев почти по всем вакансиям C#/Net наблюдается рост, а это на самом деле всего лишь сезонный рост...
Вы о чем? Какой такой сезонный рост? Я взял случайным образом 100 вакансий (в заголовках которых было либо .NET либо C#, кажется так) в августе и потом 100 вакансий в феврале, смотрел их текст и выписывал то что там упоминается. То, что в большинстве столбиков рост, говорит либо о том, что эти технологии становятся более востребованными, либо о том что работодатели постепенно хотят все больше.
Еще раз — причем тут сезонный рост и отпуска?
Весьма трезвый взгляд на вещи.
