Jump to: navigation, search

Changes

HowTo:Convert Xamarin XAMLs to Maui

931 bytes removed, 26 August
/* DataTrigger permanently blocks manual changes (use DataChangedBehavior instead) */
{{UnderConstructionStart}}
=== DataTrigger permanently blocks manual changes (use DataChangedBehavior instead) = Pre-selecting a tab based on a metaclass or property ====
In Maui, an active DataTrigger permanently blocks the user from manually switching tabs.NET MAUIFor this reason, instead of using a DataTrigger that sets to set the SelectedIndex, a property DataChangedBehavior with SetPropertyAction should be used instead, which sets SelectedIndex once when the user can also change interactively will permanently block that manual change as long as relevant data changes and leaves the trigger's condition stays true. This did not happen in Xamarin - it is a MAUItab freely user-specific behavior changechangeable afterwards.
{{HintSee [[Mobile_XAML#DataTrigger_permanently_blocks_manual_changes|MAUI ranks a value applied by an active XAML Known Issues: DataTrigger's Setter higher than a plain permanently blocks manual property write (e.g. a user's tap). Every manual write attempt is silently discarded while the trigger's condition remains true.}} In the example below a DataTrigger is used to set the selected tab based on the record's metaclass. The initial selection works correctly, but afterwards the user can never manually switch to a different tab. Tapping another tab header highlights it, but the content never switches, and SelectedIndex silently reverts. '''Workaround:''' Do not use DataTrigger changes]] for a property that should be data-driven once and then freely user-editable afterwards. Use the existing DataChangedBehavior and SetPropertyAction pattern insteadfull explanation.
{| class="wikitable" style="width:100%; table-layout:fixed;"
|}
{{Attention|This is not limited The DataChangedBehavior and SetPropertyAction Binding, ConverterParameter, and Value need to match the target tab selectionindex and condition for the specific customizing. The same problem can occur wherever a DataTrigger, Trigger, MultiTrigger sets a property that a user SetPropertyAction TargetObject must reference the UBIKTabView via x:Reference (or code-behind) is also meant to change afterwards, e.g.x:}}* Selection controls: PickerName="ContentTabs" on the UBIKTabView).SelectedIndex/SelectedItem, CollectionView/ListView.SelectedItem, RadioButton.IsChecked, Shell.CurrentItem* Toggle/input controls: Switch.IsToggled, CheckBox.IsChecked, Entry/Editor.Text* Expand/collapse state on {{Attention|This replacement applies to any control the property a DataTrigger sets that should stay user can also expand/collapse manually* Implicit/global Style.Triggers - the riskiest casechangeable afterwards, since it silently affects every control of that type not just SelectedIndex on a page* Code-behind writes executed after the trigger has already applied a value (not just touch input)TabView, see [[Mobile_XAML#DataTrigger_permanently_blocks_manual_changes|XAML Known Issues: DataTrigger permanently blocks manual changes]] for other affected controls and scenarios.}}
{{Hint|When converting a Xamarin DataTrigger, if the property it sets should remain user-changeable afterwards, convert it into a DataChangedBehavior with SetPropertyAction. Keep DataTrigger/Style.Triggers only for properties that should stay continuously data-driven and don't conflict with user input.}}
{{UnderConstructionEnd}}
CWI
791
edits
Retrieved from "https://wiki.augmensys.com/index.php?title=Special:MobileDiff/30493"