Comments 34
Оч интересно. Спасибо.
Как раз пишу UWP приложение с Fluent-дизайном. Спасибо, пригодится.
С клавиатуры ваш контрол теперь тоже не работает (провалиться в него нельзя)…
Честно говоря ожидал что в UWP создать кастомный контрол будет проще и «красивее», сейчас это похоже на кучу костылей и хождение по неопределенному поведению :(
Смотря какой. В большинстве случаев действительно не нужно спускаться на такой низкий уровень. Но рассказать эту историю мне показалось интереснее, чем что-то простое и банальное :)
Много делаю UI в WPF и могу сказать, что подобное (как в этой статье) приходится делать сплошь и рядом. А всё потому, что весь базовый набор контролов в WPF — это огромный склад костылей. И далеко не всегда есть возможность модифицировать поведение стандартных контролов.
Вот про другой контрол: Проще и без неопределённого поведения. events.yandex.ru/lib/talks/5073
UFO just landed and posted this here
Хм, а вы пробовали
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 для некоторых задач.
UFO just landed and posted this here
UFO just landed and posted this here
>> Центральный элемент как бы слегка приподнимается надо всеми остальными.
Пока это не прочитал — не видел. Стоило ли оно того?
Пока это не прочитал — не видел. Стоило ли оно того?
1. Вопрос философский. Я думаю, что из таких мелочей, в том числе, и складывается ощущение действительно хорошего приложения. Посмотрите на приложения под iOS, например — они же все прям классные. А зайдешь в Microsoft Store, там каждое второе приложение — унылое. Вот мы и пытаемся это исправлять по мере сил ;)
2. И, да, и в самом нашем приложении это выглядит заметнее, чем на gif-ке, т.к. нет такого контрастного белого фона вокруг.
2. И, да, и в самом нашем приложении это выглядит заметнее, чем на gif-ке, т.к. нет такого контрастного белого фона вокруг.
А есть вероятность того, что вы выложите его в опенсорс?
Приложение IVI для Win10 не гасит курсор после старта видео и он мешает просмотру. Это by design, отсутствующая фича, ошибка или проблема на стороне клиента? (Поддержка предложила переустановить приложение, но этот совет кажется сомнительным, на первый взгляд).
Sign up to leave a comment.
Как мы делали приложение под Windows 10 с Fluent Design (UWP/C#)