Pull to refresh

Comments 52

Молодец :) Теперь бы еще больше внутри-системных фичек :)
«Условием использования является НЕ написание программного обеспечения, конкурируемое с MS-Office линейкой. „
Достаточно обещания?
Скачать и использовать можно, пообещав мысленно. Но если софт начнет приносить заметный доход и это заметят парни из Редмонда, то будет много проблем.
WPF Ribbon
Официальная библиотека от компании Microsoft. Теоретически на ней построена линейка MS Office, но я не проверял.


MS Office — нативное приложение, никакого WPF там нет.
VS 2010 тоже нативная, однако WPF там есть
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
WPF Ribbon релизнулся и указанный минус, имхо, уже не действителен, да и выглядит он современнее, чем на вашем скриншоте. вот кстати, анонс на хабре с полезными ссылками habrahabr.ru/blogs/wpf/100833/

Т.е. уже можно писать свои MS Office приложения?
не уверен, может и нельзя. я имел в виду, что компонент теперь доступен без обращения к сайту Office UI Licensing
UFO landed and left these words here
На мой взгляд, это не честно. MS Office покрывает большое количество приложений. От средств подсчета денег до средств ввода текста. Надо почестнее бы почитать лицензию.
Расскажите, а есть ли Property Grid под WPF бесплатная и при этом работающая?
А то тут либо велосипед, либо денюжков платить другим велосипедистам
о… спасибо большое за ссылку. сам пытался много раз что-то хотябы похожее сделать, и всегда получалось криво. (на плюсик нет «заряда»)
А мне очень понравилась идея, собрать все в кучу. Дело трудоемкое, но зато очень много опльзы принесет. Можно было бы даже блог создать «ликвидатор велосипедов» и выкладывать туда не только дотнетовские разработки, но и для всех языков и платформ.
Учитывая, что мониторы сейчас преимущественно сильно шире, чем выше, интересует — есть ли хоть у одного из риббон-компонентов возможность находиться слева или справа?
Вообще, делать такое запрещает стандарт Риббона.

Но в WPF можно всё, спасибо LayoutTransform ;-)
А теперь то же самое, но чтобы Silverlight поддерживало, слабО? :)
Реквестирую отдельный пост по гридам в WPF. Очень хочется хороший грид с поддержкой групирования, сортировки и редактирования.
А еще про различные chart-контролы.
Следующий пост будет по компонентам :)
Люто, бешено не хватает WPF NumericInput'а, для текстового ввода цифровых значений. Желательно Blend-like. Само собой, с поддержкой границ, кол-ва знаков после запятой и всего такого. Я пытался слямзить этот компонент из как раз таки Blend'а, но не потянул. Там NumericInput постоен на целой иерархии проприетарных компонентов. Правда, кто-нибудь владеющий Reflector'ом и имеющий свободное время, думаю, осилил бы.

Еще сильно хотелось бы заиметь WPF Balloon'ы. В принципе это суть стиль PopupControl'а, но самому лень делать.
Посмотрел — требуемой функциональностью и не пахнет, контроль ввода осуществляется тупо 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

И так почти всегда!
Меня очень сильно напрягает что необходимо делать кучу доп классов. В итоге приложение похоже на толстое нечто, которое обслуживает библиотеку, и при этом намного раздутее WinForms аналога.
Подскажите, какие есть готовые бесплатные либы для аплоада файлов по FTP?
А то я пока через LibCurlNet юзаю libcurl, но скорость аплоада под виндой у него не очень… Под *nix — полностью канал использует, под виндой (даже консольный курл) — процентов на 10-20…
А не лучше ли купить нормальный велик один раз, чем городить ribbon — отсюда, dock — оттуда, chart взять ещё где-то, grid в четвёртом месте и т.д.? У всех разные API, разные скины, разные пространства имен, разного уровня примеры и документация.
… вот и мне интересно.
Вообще-то, фреймворк задаёт общий стиль для API, но все разработчики библиотек-расширений его придерживаются.
Реализация от Microsoft кажется вам менее привлекательной чем от стороннего разработчика?
Странный вопрос.

Наверное вы имеете в виду, что раз Майкрософт разработала стандарт на Риббон, то их контрол будет точнее следовать этому стандарту? Но поверьте, все производители сторонних риббонов обычно хорошо знакомы с этим стандартом и следуют ему с той же точностью, что и Майкрософт. Иначе они бы не выжили.

Если же вы имеете в виду, что контрол от Майкрософт всегда лучше по функциональности, то это тоже не совсем так. Не берусь утверждать насчёт всех риббонов, но если взять любой грид от МС, то у кучи сторонних производителей гриды будут гораздо лучше.
Если не видно разницы, зачем платить больше? :)
Если не видно, то конечно незачем :-) Всё зависит от ваших потребностей и возможностей.

В конце концов, всегда можно сделать наследника от MSовского контрола и реализовать недостающий функционал. Вот только очень часто там что-то нужное бывает закрыто, к сожалению :-(
В Телерик-контролы понапихано всякой хрени, 80% которой на фиг не сдалось. Столкнулись с этим при разработки web-application.

Сейчас безумно рад, что не связались с этой библиотекой — отдел маркетинга ставит такие задачи, что если решать их Телериком, приложение давно бы превратилось в большую навозную кучу.

В общем библиотека для «пионеров», которые диктуют бизнесу каким должно быть приложение, а не наоборот.
В Телерик-контролы понапихано всякой хрени, 80% которой на фиг не сдалось.
Так пользуйтесь оставшимися 20%, что помешало?

Сейчас безумно рад, что не связались с этой библиотекой — отдел маркетинга ставит такие задачи, что если решать их Телериком, приложение давно бы превратилось в большую навозную кучу.
Ну да, а понаписав кучу своих велосипедов, получилась конфета
Если нужно делать композитные приложения, функциональность которого можно гибко менять в зависимости от подключенных плагинов, то нужно обратить внимание на проект 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, чтобы сделать кнопку в заголовке:

Не подскажите, как сделать?
А портируемые оконные менеджеры по какой причне в список не попали?
Какие именно менеджеры Вы имели ввиду? Блог — .NET
Only those users with full accounts are able to leave comments. Log in, please.