Комментарии 34
Оч интересно. Спасибо.
Как раз пишу UWP приложение с Fluent-дизайном. Спасибо, пригодится.
С клавиатуры ваш контрол теперь тоже не работает (провалиться в него нельзя)…
Честно говоря ожидал что в UWP создать кастомный контрол будет проще и «красивее», сейчас это похоже на кучу костылей и хождение по неопределенному поведению :(
Смотря какой. В большинстве случаев действительно не нужно спускаться на такой низкий уровень. Но рассказать эту историю мне показалось интереснее, чем что-то простое и банальное :)
Много делаю UI в WPF и могу сказать, что подобное (как в этой статье) приходится делать сплошь и рядом. А всё потому, что весь базовый набор контролов в WPF — это огромный склад костылей. И далеко не всегда есть возможность модифицировать поведение стандартных контролов.
Вот про другой контрол: Проще и без неопределённого поведения. events.yandex.ru/lib/talks/5073
Хм, а вы пробовали
1) в случае гридвью в OnSizeChanged находить ScrollViewer и вызывать у него InvalidateScrollInfo чтоб он дальше все сам делал?
2) вместо полностью кастомного скрола, просто отнаследоваться от ScrollViewer и переопределить метод OnPointerWheelChanged с пустым телом?
1) в случае гридвью в OnSizeChanged находить ScrollViewer и вызывать у него InvalidateScrollInfo чтоб он дальше все сам делал?
2) вместо полностью кастомного скрола, просто отнаследоваться от ScrollViewer и переопределить метод OnPointerWheelChanged с пустым телом?
1) Не понял мысль. ScrollViewer.InvalidateScrollInfo ведь ничего не знает о том, что внутри него лежит панель, внутри которой изменились размеры элементов. Как он сможет рассчитать новое значение HorizontalOffset?
2) ScrollViewer в UWP объявлен как sealed. От него нельзя унаследоваться. А так да, это было бы хорошее решение.
2) ScrollViewer в UWP объявлен как sealed. От него нельзя унаследоваться. А так да, это было бы хорошее решение.
2) Действительно, проглядел. Обидно. Остается рефлексия
1) размеры элементов изменились, они инвалидируют свой размер и уведомляют родительскую панель. Панель тоже пересчитывает свой размер и перерендеривает себя. По каким-то причинам до скролвьювера не доходит информация о том, что изменились снаппойнты и размер скролящейся области. Идея в том, что если ему сообщить, что данные устарели (а это как раз InvalidateScrollInfo), то он должен опросить панель у которой уже есть новая информация.
1) размеры элементов изменились, они инвалидируют свой размер и уведомляют родительскую панель. Панель тоже пересчитывает свой размер и перерендеривает себя. По каким-то причинам до скролвьювера не доходит информация о том, что изменились снаппойнты и размер скролящейся области. Идея в том, что если ему сообщить, что данные устарели (а это как раз InvalidateScrollInfo), то он должен опросить панель у которой уже есть новая информация.
Попробовал сейчас на примере AdaptiveGridView из UwpToolkit-а. Само по себе — это ни на что не влияет:
Ещё попробовал InvalidateScrollInfo использовать в паре с scrollViewer.ChangeView. И снова непредсказуемый результат при максимизации окна.
private void OnSizeChanged(object sender, SizeChangedEventArgs e)
{
if (e.PreviousSize.Width != e.NewSize.Width)
{
RecalculateLayout(e.NewSize.Width);
}
var scrollViewer = this.FindDescendant<ScrollViewer>();
scrollViewer.InvalidateScrollInfo();
}Ещё попробовал InvalidateScrollInfo использовать в паре с scrollViewer.ChangeView. И снова непредсказуемый результат при максимизации окна.
Я правильно понимаю, что весь этот Composition надо писать в codebehind и на XAML далеко не уедешь?
Исходно, да — вся работа с Composition пишется на C#. Но никто не мешает писать свои Behavior-ы и Attached-свойства и цеплять их через XAML.
Собственно, ребята из Microsoft именно это уже и делают в UwpToolkit: Blur, Reorder Grid, Параллакс и др. Посмотрите поподробнее, там много всего удобного.
А когда готовых компонентов из UwpToolkit-а становится мало, тогда начинаешь писать свои уже на C#.
Собственно, ребята из Microsoft именно это уже и делают в UwpToolkit: Blur, Reorder Grid, Параллакс и др. Посмотрите поподробнее, там много всего удобного.
А когда готовых компонентов из UwpToolkit-а становится мало, тогда начинаешь писать свои уже на C#.
Пока да. Я для себя сделал Behavior для некоторых задач.
Так вся соль в этих крайних элементах. Без них такие анимации будут выглядеть ущербно. Поверьте, мы пробовали.
Плюс проблема с вложенными ScrollViewer-ами никуда не денется с FlipView.
Плюс проблема с вложенными ScrollViewer-ами никуда не денется с FlipView.
>> Центральный элемент как бы слегка приподнимается надо всеми остальными.
Пока это не прочитал — не видел. Стоило ли оно того?
Пока это не прочитал — не видел. Стоило ли оно того?
1. Вопрос философский. Я думаю, что из таких мелочей, в том числе, и складывается ощущение действительно хорошего приложения. Посмотрите на приложения под iOS, например — они же все прям классные. А зайдешь в Microsoft Store, там каждое второе приложение — унылое. Вот мы и пытаемся это исправлять по мере сил ;)
2. И, да, и в самом нашем приложении это выглядит заметнее, чем на gif-ке, т.к. нет такого контрастного белого фона вокруг.
2. И, да, и в самом нашем приложении это выглядит заметнее, чем на gif-ке, т.к. нет такого контрастного белого фона вокруг.
А есть вероятность того, что вы выложите его в опенсорс?
Приложение IVI для Win10 не гасит курсор после старта видео и он мешает просмотру. Это by design, отсутствующая фича, ошибка или проблема на стороне клиента? (Поддержка предложила переустановить приложение, но этот совет кажется сомнительным, на первый взгляд).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы делали приложение под Windows 10 с Fluent Design (UWP/C#)