Úprava viditelnosti pojmenovaných XAML elementů

Atribut x:Name v XAMLu vytváří pro elementy členské položky třídy, které lze použít pro přístup k ovladacím prvkům z kódu. Narozdíl od WPF však v UWP jsou tyto položky třídy definovány jako private, což znamená, že k nim je možné přistupovat pouze z třídy samotné. Pokud vezmeme v potaz, že z hlediska architektury by to byl špatný nápad, je možné toto chování změnit? Pokračovat ve čtení “Úprava viditelnosti pojmenovaných XAML elementů”

Modifying XAML named field visibility

The x:Name attribute in XAML creates named fields that you can use to access the controls from the code-behind. However, as opposed to WPF, in UWP these fields are private which means you can access them from the code-behind only, not from other classes. While noting it is a good idea from architectural standpoint, is it possible to change this behavior? Pokračovat ve čtení “Modifying XAML named field visibility”

When a single transparent color is simply not enough

There are countless times in the life of a Universal Windows Platform app developer when the “Transparent” color comes handy. However, it is good to remember that “Transparent” is still just a color, otherwise you can encounter some unwelcome surprises.

Animation of "Transparent" color
On the left is the animation from “Transparent” to White, on the right from “Transparent” to Black

Pokračovat ve čtení “When a single transparent color is simply not enough”

Device family state trigger pro UWP

Univerzální platforma Windows funguje na mnoha různých typech zařízení (device family). Aby aplikace vypadala skvěle na různých zařízeních, většinou lze použít AdaptiveTrigger, který reaguje na různá rozlišení displeje. Pokud však potřebujeme cílit na konkrétní rodinu zařízení, je možné si pro tento účel vytvořit vlastní state trigger. Pokračovat ve čtení “Device family state trigger pro UWP”

Tip: Roztažení položek seznamu v UWP na šířku

Ovládací prvky ListView a ListBox v univerzální platformě Windows je možné snadno využít pro zobrazení seznamů v uživatelském rozhraní aplikace. Ve výchozí podobě zabírají jednotlivé položky seznamu pouze ten prostor, který skutečně potřebují, což se často nehodí, protože je chceme roztáhnout na celou šířku ovládacího prvku. Jak toho dosáhnout?

Ve výchozí podobě jsou prvky zarovnané vlevo. Jak je roztáhnout?

Pokračovat ve čtení “Tip: Roztažení položek seznamu v UWP na šířku”

Tip: Stretching list items in UWP

The UWP ListView and ListBox  controls can be used to present lists of items in the user interface. By default the items are left-aligned and take up just the space they require, which is unfortunate if you want to stretch them to the full available width of the list control. How to achieve that?

By default, list items are left aligned, how to stretch them?

Pokračovat ve čtení “Tip: Stretching list items in UWP”

Jak vynutit otevření CommandBaru směrem dolů

Ovládací prvek CommandBar  je důležitou komponentou pro design UWP aplikací. Jde o evoluci konceptu   AppBar , který je dostupný již od dob Windows Phone 7, ale v případě UWP má výrazně více funkcí. Stále však chybí možnost určit směr, kterým se command bar bude otevírat.

Problém

Výchozí chování CommandBaru je otevření směrem nahoru vždy, kdy není na samotném horním okraji okna. To je problém, protože toto platí i v případě, že definujeme vlastní title bar aplikace na Desktopu, kdy se   CommandBar  otevře pod tlačítka minimalizace, maximalizace a zavření okna a to rozhodně nevypadá dobře.

Výchozí šablona

Výchozí šablona prvku CommandBar  definuje kolekce VisualState  a  VisualStateTransition , které určují, jak bude prvek vypadat. Můžeme si všimnout že je vždy separátně definován stav pro otevření směrem dolů a nahoru.

Uvnitř těchto stavů můžeme vidět, že systém jen používá různé hodnoty pro některé z vlastností jako například CommandBarTemplateSettings.ContentHeight  resp. CommandBarTemplateSettings.NegativeOverflowContentHeight  pro vlastnost  Y  u transformace OverflowContentRootTransform .

Řešení

Nemůžeme snadno modifikovat vnitřní logiku ovladacího prvku, ale můžeme zajistit, že bude vypadat pro stav otevření nahoru identicky jako pro otevření dolů. Toho můžeme dosáhnout čistě překopírováním Storyboardů  ze stavů a přechodů se obsahujících ...OpenDown do jim odpovídajících  ...OpenUp  protějšků. Bohužel manuální překopírování je jediná možnost. Bylo by sice také možné jednotlivé Storyboardy  převést na samostatné resource, ale bohužel je pro VisualState  a VisualStateTransition nelze referencovat pomocí syntaxe {StaticResource}.

Pro získání kompletní kopie výchozího stylu olvadacího prvku můžeme buď použít Visual Studio XAML Designer (klepněte na prvek pravým tlačítkem myši, vyberte Edit Template a Edit a Copy…), nebo ji lze vyhledat na v souboru   C:\Program Files (x86)\Windows Kits\10\DesignTime\CommonConfiguration\Neutral\UAP{version}\Generic\generic.xaml

Abych vám ušetřil klávesy  Ctrl , C  a V , připravil jsem kompletní upravený styl, který můžete přímo použít ve vaší aplikaci. Styl je ke stažení na mém GitHubu spolu s ukázkovým projektem k tomuto článku. Upozorňuji, že můj definovaný styl je pro verzi Anniversary Update. Pro budoucí verze doporučuji změny provést manuálně na aktuální šabloně.

Shrnutí

CommandBar  je skvělý ovladací prvek, který většinou funguje přesně tak, jak potřebujeme. Když však narazíme na problém, můžeme jeho šablonu poměrně snadno modifikovat.

Forcing the CommandBar to open down

The CommandBar  control is a vital component of UWP app design. It is an evolution of the AppBar  concept, which was available ever since Windows Phone 7, but with UWP is much more feature complete. One thing that is still missing however is the option to choose the direction in which the command bar opens.

Problem

The default behavior of the CommandBar  is to open in the up direction whenever the control is not at the very top of the window. This is an issue, because this holds true even when we define a custom title bar on Desktop, in which case the CommandBar  opens below the window’s minimize, maximize and close buttons which doesn’t look good at all.

The default template

The default template of the CommandBar  control defines the states of the control as a collection of VisualStates  and VisualStateTransitions . It turns out that there is always a separate visual state for down and up direction.

Inside these states you can see that the system just uses different values for some of the properties like CommandBarTemplateSettings.ContentHeight  vs CommandBarTemplateSettings.NegativeOverflowContentHeight  for the Y  property of OverflowContentRootTransform .

Solution

We cannot easily change the inner logic of the control itself, but we can make the control in up-open state look identical as it does for down-open state. This can be achieved purely by copy-pasting the Storyboards  from ...OpenDown visual states and visual state transitions to the respective ...OpenUp  counterparts. Unfortunately the manual copy-pasting is the only option, because extracting the Storyboards  into separate resources and referencing them with {StaticResource} isn’t supported.

To get a full copy of the default control style you can use either the XAML Designer (right-click the control, select Edit Template and Edit a Copy…), or search for it in C:\Program Files (x86)\Windows Kits\10\DesignTime\CommonConfiguration\Neutral\UAP{version}\Generic\generic.xaml

To spare your Ctrl , C  and V  keys, I have prepared the full modified style which you can take and use in your app. You can get this style here on my GitHub along with the full sample project for this article. Beware that this style targets the Anniversary Update. I recommend doing the changes manually if you target a different version.

Summary

The CommandBar  is a great control that works as we expect most of the time. When we hit an issue however, its template is quite easy to modify.

How to add new preview devices to the XAML Designer

The Visual Studio XAML Designer for Universal Windows Platform offers design-time device previews for several different screens size and scaling combos. Unfortunately, the default selection might not be sufficient for you in some cases, especially when you want to optimize for a specific screen. Is it possible to expand the selection with more devices?

Default device offering in Visual Studio

Pokračovat ve čtení “How to add new preview devices to the XAML Designer”