Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 52
Молодец :) Теперь бы еще больше внутри-системных фичек :)
«Условием использования является НЕ написание программного обеспечения, конкурируемое с MS-Office линейкой. „
Достаточно обещания?
Достаточно обещания?
WPF Ribbon
Официальная библиотека от компании Microsoft. Теоретически на ней построена линейка MS Office, но я не проверял.
MS Office — нативное приложение, никакого WPF там нет.
VS 2010 тоже нативная, однако WPF там есть
Нет, VS2010 — это как раз .Net-приложение с GUI переписанным на WPF.
большая часть VS 2010 написана на managed code. Визульная часть как раз на WPF: «The IDE shell has been rewritten using the Windows Presentation Foundation (WPF)» via en.wikipedia.org/wiki/Microsoft_Visual_Studio#Visual_Studio_2010
Ribbon из MS Office написан на C++ и он есть! в Visual Studio по умолчанию (никакого WPF).
Ribbon который вывешен на Codeplex написан на WPF, но насколько мне известно в продуктах MS не используется.
Fluent Ribbon был написан как раз в ответ на этот кривой Ribbon.
Итог? Реальный WPF Ribbon от Microsoft берем здесь www.microsoft.com/downloads/en/details.aspx?FamilyID=2BFC3187-74AA-4154-A670-76EF8BC2A0B4
Ribbon который вывешен на Codeplex написан на WPF, но насколько мне известно в продуктах MS не используется.
Fluent Ribbon был написан как раз в ответ на этот кривой Ribbon.
Итог? Реальный WPF Ribbon от Microsoft берем здесь www.microsoft.com/downloads/en/details.aspx?FamilyID=2BFC3187-74AA-4154-A670-76EF8BC2A0B4
WPF Ribbon релизнулся и указанный минус, имхо, уже не действителен, да и выглядит он современнее, чем на вашем скриншоте. вот кстати, анонс на хабре с полезными ссылками habrahabr.ru/blogs/wpf/100833/
Расскажите, а есть ли Property Grid под WPF бесплатная и при этом работающая?
А то тут либо велосипед, либо денюжков платить другим велосипедистам
А то тут либо велосипед, либо денюжков платить другим велосипедистам
Есть неплохой вариант: wpg.codeplex.com/
А мне очень понравилась идея, собрать все в кучу. Дело трудоемкое, но зато очень много опльзы принесет. Можно было бы даже блог создать «ликвидатор велосипедов» и выкладывать туда не только дотнетовские разработки, но и для всех языков и платформ.
Учитывая, что мониторы сейчас преимущественно сильно шире, чем выше, интересует — есть ли хоть у одного из риббон-компонентов возможность находиться слева или справа?
А теперь то же самое, но чтобы Silverlight поддерживало, слабО? :)
Под SL более менее приличный риббон пока есть только за двести баксов.
Реквестирую отдельный пост по гридам в WPF. Очень хочется хороший грид с поддержкой групирования, сортировки и редактирования.
А еще про различные chart-контролы.
А еще про различные chart-контролы.
Люто, бешено не хватает WPF NumericInput'а, для текстового ввода цифровых значений. Желательно Blend-like. Само собой, с поддержкой границ, кол-ва знаков после запятой и всего такого. Я пытался слямзить этот компонент из как раз таки Blend'а, но не потянул. Там NumericInput постоен на целой иерархии проприетарных компонентов. Правда, кто-нибудь владеющий Reflector'ом и имеющий свободное время, думаю, осилил бы.
Еще сильно хотелось бы заиметь WPF Balloon'ы. В принципе это суть стиль PopupControl'а, но самому лень делать.
Еще сильно хотелось бы заиметь WPF Balloon'ы. В принципе это суть стиль PopupControl'а, но самому лень делать.
NumericUpDn был визуально замечен в http://wpg.codeplex.com/
Посмотрел — требуемой функциональностью и не пахнет, контроль ввода осуществляется тупо unhandled exception'ами :-/
Никогда не понимал, почему MS не включил в список стандартных компонент все компоненты из WinForms…
Да, WPF такая мощная инновационная нанотехнология технология, а элементарных вещей нету :( Забабахать видео и рабочие контролы на трёхмерном интерактивном кубе — это как 2 пальца об асфальт, а вот сварганить реальное работающее прикладное приложение — обосраться и не встать. И во многом по причине отсутствия некоторых базовых элементов управления и функциональности.
Накипело:
Еще MS разработчики WPF контролов по крупному облажались с TreeView. Без специально написанной объектной модели компонент не функционален чуть более, чем никак. Если тупо пихать TreeViewItem'ы в коллекции — прощай виртуализация GUI — не вариант, когда нужна масштабируемость, да и концептуально подход неверный. Если использовать пропиаренный HierarchicalDataTemplate — Items руками не трогать! Из-за логики отложенной генерации контейнеров, некоторых TreeViewItem'ом в дереве может просто еще не существовать, и при попытке развернуть какую-нибудь ветку до требуемого узла получим былинный отказ. Т.е. компонент становится «неприкасаемым» для кода. Единственный рабочий вариант — писать ModelView для источника иерархических данных, где в элементе модели уже держать свойства IsExpanded, Visibility и т.д. В MS могли бы и сами этим озаботиться!
Ну и самая, на мой взгляд, жирная какашка в WPF, вылезающая отовсюду при попытке реализации нестандартного поведения контрола, заключается в том, что при новой концепции композиции вида элементов — шаблоны, стили, присоединяемые свойства, неизменной осталась реализация обработки пользовательского ввода — методом сабклассинга. Роутинг событий-то штука крайне полезная, удобная, да и вообще. Только вот protected virtual void OnXXX(RoutedEventArgs e) { e.Handled = true; } убивает все преимущества на корню.
Пробовали когда-нибудь в WPF сделать Drag & Drop из, например, ListView? Казалось бы:
— Помещаем в шаблон ListViewItem — Thumb.
— Обрабатываем OnDragStarted.
— ?????
— PROFIT
Но не тут то было! Добрая «тумба» обрабатывает событие опускания мыши и фокусируется. Соответственно ListViewItem уже опускание мыши не получает, и не выделяется. Так что тут или выделяющийся Item или перетаскиваемый. Поэтому, остаётся один вариант — пишем DraggableListViewItem: ListViewItem, переопределяем OnMouseDown, OnMouseUp, OnMouseMove, при этом:
— Полагаемся на детали базовой реализации методов ListViewItem.
— Переносим в ListViewItem функционал класса Thumb.
— ?????
— FUUUUUUUUUUU
И так почти всегда!
Накипело:
Еще MS разработчики WPF контролов по крупному облажались с TreeView. Без специально написанной объектной модели компонент не функционален чуть более, чем никак. Если тупо пихать TreeViewItem'ы в коллекции — прощай виртуализация GUI — не вариант, когда нужна масштабируемость, да и концептуально подход неверный. Если использовать пропиаренный HierarchicalDataTemplate — Items руками не трогать! Из-за логики отложенной генерации контейнеров, некоторых TreeViewItem'ом в дереве может просто еще не существовать, и при попытке развернуть какую-нибудь ветку до требуемого узла получим былинный отказ. Т.е. компонент становится «неприкасаемым» для кода. Единственный рабочий вариант — писать ModelView для источника иерархических данных, где в элементе модели уже держать свойства IsExpanded, Visibility и т.д. В MS могли бы и сами этим озаботиться!
Ну и самая, на мой взгляд, жирная какашка в WPF, вылезающая отовсюду при попытке реализации нестандартного поведения контрола, заключается в том, что при новой концепции композиции вида элементов — шаблоны, стили, присоединяемые свойства, неизменной осталась реализация обработки пользовательского ввода — методом сабклассинга. Роутинг событий-то штука крайне полезная, удобная, да и вообще. Только вот protected virtual void OnXXX(RoutedEventArgs e) { e.Handled = true; } убивает все преимущества на корню.
Пробовали когда-нибудь в WPF сделать Drag & Drop из, например, ListView? Казалось бы:
— Помещаем в шаблон ListViewItem — Thumb.
— Обрабатываем OnDragStarted.
— ?????
— PROFIT
Но не тут то было! Добрая «тумба» обрабатывает событие опускания мыши и фокусируется. Соответственно ListViewItem уже опускание мыши не получает, и не выделяется. Так что тут или выделяющийся Item или перетаскиваемый. Поэтому, остаётся один вариант — пишем DraggableListViewItem: ListViewItem, переопределяем OnMouseDown, OnMouseUp, OnMouseMove, при этом:
— Полагаемся на детали базовой реализации методов ListViewItem.
— Переносим в ListViewItem функционал класса Thumb.
— ?????
— FUUUUUUUUUUU
И так почти всегда!
Подскажите, какие есть готовые бесплатные либы для аплоада файлов по FTP?
А то я пока через LibCurlNet юзаю libcurl, но скорость аплоада под виндой у него не очень… Под *nix — полностью канал использует, под виндой (даже консольный курл) — процентов на 10-20…
А то я пока через LibCurlNet юзаю libcurl, но скорость аплоада под виндой у него не очень… Под *nix — полностью канал использует, под виндой (даже консольный курл) — процентов на 10-20…
… вот и мне интересно.
А я присматриваюсь к этому.
Вообще-то, фреймворк задаёт общий стиль для API, но все разработчики библиотек-расширений его придерживаются.
Реализация от Microsoft кажется вам менее привлекательной чем от стороннего разработчика?
Странный вопрос.
Наверное вы имеете в виду, что раз Майкрософт разработала стандарт на Риббон, то их контрол будет точнее следовать этому стандарту? Но поверьте, все производители сторонних риббонов обычно хорошо знакомы с этим стандартом и следуют ему с той же точностью, что и Майкрософт. Иначе они бы не выжили.
Если же вы имеете в виду, что контрол от Майкрософт всегда лучше по функциональности, то это тоже не совсем так. Не берусь утверждать насчёт всех риббонов, но если взять любой грид от МС, то у кучи сторонних производителей гриды будут гораздо лучше.
Наверное вы имеете в виду, что раз Майкрософт разработала стандарт на Риббон, то их контрол будет точнее следовать этому стандарту? Но поверьте, все производители сторонних риббонов обычно хорошо знакомы с этим стандартом и следуют ему с той же точностью, что и Майкрософт. Иначе они бы не выжили.
Если же вы имеете в виду, что контрол от Майкрософт всегда лучше по функциональности, то это тоже не совсем так. Не берусь утверждать насчёт всех риббонов, но если взять любой грид от МС, то у кучи сторонних производителей гриды будут гораздо лучше.
В Телерик-контролы понапихано всякой хрени, 80% которой на фиг не сдалось. Столкнулись с этим при разработки web-application.
Сейчас безумно рад, что не связались с этой библиотекой — отдел маркетинга ставит такие задачи, что если решать их Телериком, приложение давно бы превратилось в большую навозную кучу.
В общем библиотека для «пионеров», которые диктуют бизнесу каким должно быть приложение, а не наоборот.
Сейчас безумно рад, что не связались с этой библиотекой — отдел маркетинга ставит такие задачи, что если решать их Телериком, приложение давно бы превратилось в большую навозную кучу.
В общем библиотека для «пионеров», которые диктуют бизнесу каким должно быть приложение, а не наоборот.
Если нужно делать композитные приложения, функциональность которого можно гибко менять в зависимости от подключенных плагинов, то нужно обратить внимание на проект Orchestra. Он уже интегрирует в себя такие библиотеки как Prism (для работы с плагинами, их поиска и загрузки), Fluent Ribbon (меню в стиле Microsoft Word), AvalonDock (окна которые можно перемещать, вставлять друг в друга, прикреплять, как в Visual studio) и построен на базе фраймворка Catel (упрощает создание программ в стиле MVVM). При этом не нужно знаний библиотек Prism, AvalonDock, Ribbon.
А можно найти Ribbon для WinForms (боле менее рабочий хотелось бы)?
Я не смотрел, поищу, но реализация Ribbon под GDI+ будет гораздо более трудоемкой, поскольку Ribbon настроен на векторный вывод все-таки. Как заметили выше, Office не пользуется WPF, потому я преклоняюсь перед этой командой, что они реализовали в 2007 и 2010. Скорее всего это будут библиотеки с ограниченными возможностями (относительно WPF)
А в чем проблема? Что у телерика, что у девекса.
Наиболее стандартный способ для C# WinForms, чтобы сделать кнопку в заголовке:
Не подскажите, как сделать?
Не подскажите, как сделать?
А портируемые оконные менеджеры по какой причне в список не попали?
Интересно, спасибо за ссылки!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ликвидатор велосипедов: часть 1