I'm trying to add Pan and Zoom to custom user control in Avalonia 0.10.10 using mouse wheel and mouse move events.
Standard avalonia template
dotnet new avalonia.mvvm -o Demo
User Control XAML
<UserControl
xmlns="https://github.com/avaloniaui"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="d" d:DesignWidth="800" d:DesignHeight="450"
x:Class="CrossCanvas.Views.Avalonia.CanvasView">
</UserControl>
User Control
public partial class CanvasView : UserControl // Canvas
{
public CanvasView()
{
AvaloniaXamlLoader.Load(this);
PointerMoved += OnMouseMove;
PointerWheelChanged += OnWheel;
}
protected void OnWheel(object sender, PointerWheelEventArgs e) {}
protected void OnMouseMove(object sender, PointerEventArgs e) {}
}
Code that was used as an example
https://github.com/AvaloniaUI/Avalonia/issues/2492#issuecomment-489898224
The issue
No matter where I add new event handlers, in the constructor or in EndInit handler, these events are not being triggered. Maybe Avalonia 0.10.10 had some breaking changes or I do something wrong?
UserControl is invisible for hit test (pointer input) for obvious reasons to avoid it being blocking input from any other control behind it.
But you can easily make it visible for hit test by making it "visible" - set Background to non-null value. For example, "Transparent".
Related
I'm trying to detect the scale manipulation (pinch) in my application but for some reason the events are not invoked consistently (sometimes they are, sometimes they are not).
I've created a sample application where this can be easily reproduced:
<Page
x:Class="Manipulate.MainPage"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="d"
Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
<Grid Background="Red" ManipulationMode="Scale" ManipulationDelta="Grid_ManipulationDelta" ManipulationStarted="Grid_ManipulationStarted"/>
</Page>
using Windows.UI.Xaml.Controls;
using Windows.UI.Xaml.Input;
namespace Manipulate
{
public sealed partial class MainPage : Page
{
public MainPage()
{
this.InitializeComponent();
}
private void Grid_ManipulationStarted(object sender, ManipulationStartedRoutedEventArgs e)
{
System.Diagnostics.Debug.WriteLine($"Started {e.}");
}
private void Grid_ManipulationDelta(object sender, ManipulationDeltaRoutedEventArgs e)
{
System.Diagnostics.Debug.WriteLine($"Delta {e.Delta.Scale}");
}
}
}
In my actual application I'm trying to implement pinch to zoom on our custom camera implementation (inspired by https://github.com/microsoft/Windows-universal-samples/tree/master/Samples/CameraManualControls) however I can't seem to get it work because neither ManipulationStarted nor ManipulationDelta are invoked consistently on every pinch gesture.
I'm seeing this on multiple Surface devices (Surface Book, Surface Go, Surface Pro 4).
Please check this Touch interactions document.
Pinch Manipulation gesture Two or more fingers touch the screen and move closer together. In other words, you need to closer two pressed fingers. I have tested with simulator, and it works well. And here is sample code that you could refer.
_compositeTransform.ScaleX = _compositeTransform.ScaleY = e.Delta.Scale;
Update
Derive from #Cosmin It seems there was an issue in the Windows build I was using 20226.1000. The issue was fixed Please check the blog here.
I want to show a flyout at a specific place. I want to specify a placement target element in XAML, but I want to make sure I am using the "lightest" element possible, given that I don't want that element to ever be visible or interacted with.
Is there a "recommended" or "correct" element to use? If not, what would be the "lightest" element to use? Or am I overthinking this and should just use a button?
I want to show a flyout at a specific place.
The place of FrameworkElements are based on the panel that you are using to hold them. If you want to show your flyout based on a FrameworkElement being placed in a specific place, you can use Canvas to position your FrameworkElement.
I want to specify a placement target element in XAML, but I want to make sure I am using the "lightest" element possible.
Flyout.ShowAt takes FrameworkElement as it's placement target. So I think the "lightest" element would be an empty custom FrameworkElement like below:
public class MyElement:FrameworkElement
{
}
And you can put it into XAML and use Canvas to position it:
<Page
x:Class="PopupSample.MainPage"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="using:PopupSample"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="d">
<Canvas>
<Button Name="btnClick" Canvas.Left="50" Canvas.Top="500" Click="btnClick_Click">Click Me</Button>
<local:MyElement x:Name="myEle" Canvas.Left="100" Canvas.Top="100"></local:MyElement>
</Canvas>
Code-Behind:
public sealed partial class MainPage : Page
{
public MainPage()
{
this.InitializeComponent();
}
private void btnClick_Click(object sender, RoutedEventArgs e)
{
Flyout flyout = new Flyout();
TextBlock tbContent = new TextBlock
{
Text= "this is a flyout content"
};
flyout.Content = tbContent;
flyout.ShowAt(myEle);
}
}
Grid is a pretty light element, it's just a simple Panel-derived class without any child elements. Button is a Control, meaning it has a template which will create many child elements that make up its visual appearance.
Are you saying you want to use a dummy element just for the purpose of specifying the position of the flyout which you will show programmatically? If you want to avoid the element altogether, then maybe a Popup would be a better choice.
I have created a content dialog for my UWP app which involves a centralized UI Element and a surrounding blank area.But content dialog does not have a property like "IsLightDismissEnabled" to close the dialog on click on an area except the UIELEMENT area.How can I achieve it?
In the code behind your content dialog:
public sealed partial class CustomDialog : ContentDialog
{
public CustomDialog()
{
this.InitializeComponent();
Boolean isHide;
Window.Current.CoreWindow.PointerPressed += (s, e) =>
{
if (isHide)
Hide();
};
PointerExited += (s, e) => isHide = true;
PointerEntered += (s, e) => isHide = false;
}
}
There are few options that I can think of:
Use popup (like uruk suggested) and add your controls inside, create the popup at desired location (you could also use binding here if you want to show the popup at location depending on user input at runtime Popup has HorizontalOffset and VerticalOffset properties)
Create a parent view that is taking up the whole page but is transparent, then add your UI elements at the center and attach tap/click events to the transparent view. These events are going to just close remove/collapse the transparent view which contains the other elements inside (Either by binding of values or by setting the values to the UI elements).
Example or popup usage:
<Popup x:Name="MenuPopUp"
IsLightDismissEnabled="True"
HorizontalOffset="{Binding HorizontalOffset}"
VerticalOffset="{Binding VerticalOffset}"
IsOpen="{Binding IsOpen, Mode=TwoWay}">
<Grid>
YOUR ELEMENTS HERE
</Grid>
</Popup>
Content dialog is a modal dialog. Why don't you use a Popup or a child class of it? It's non-modal, and it already has the IsLightDismissEnabled property you just mentioned.
<Popup x:Name="MenuPopUp"
IsLightDismissEnabled="True"
LostFocus="MenuPopUp_LostFocus"/>
In CS
private void MenuPopUp_LostFocus(object sender, RoutedEventArgs e)
{
MenuPopup.IsOpen = false;
}
I'd like to get the actual width of an image in my WP8.1 app. The width cannot be determined (i.e. is zero) until the page has been rendered, and other solutions suggest handling this in the page loaded event as in the basic example below. But even here, img.ActualWidth is zero.
How can I retrieve img.ActualWidth once as soon as the page is rendered?
public sealed partial class MainPage : Page {
public MainPage() {
this.InitializeComponent();
this.NavigationCacheMode = NavigationCacheMode.Required;
this.Loaded += MainPage_Loaded;
}
private void MainPage_Loaded(object sender, RoutedEventArgs e) {
Debug.WriteLine(img.ActualWidth);
}
}
and
<Page
x:Class="Page_Loaded.MainPage"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="using:Page_Loaded"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="d"
Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
<Grid>
<Image x:Name="img" Source="/image.jpg" />
</Grid>
</Page>
Use SizeChanged event handler. It occurs when either the ActualHeight or the ActualWidth property changes value on a FrameworkElement.
ActualWidth is a calculated property. The calculations are a result of a layout pass, where the object is sized in layout according to the logic of its successive layout parents.
The default of ActualWidth is 0. The default might be encountered if the object has not been loaded and hasn't yet been involved in a layout pass that renders the UI. (This is happening in your case)
ActualWidth can have multiple or incremental reported changes to the value because of operations by the layout system. If you get the value while layout is still iterating, the layout system might still be calculating the required measure of space for child objects, constraints by the parent object, and so on. Because the value is based on an actual rendering pass, it may lag slightly behind the set value of properties like Width, which can be the basis of the input change.
For purposes of ElementName binding, ActualWidth does not post updates when it changes (due to its asynchronous and run-time calculated nature). Do not attempt to use ActualWidth as a binding source for an ElementName binding. If you have a scenario that requires updates based on ActualWidth, use a SizeChanged handler.
SizeChanged fires whenever the size (either ActualHeight or ActualWidth) has changed on the object, which is after the Measure and Arrange passes are complete. One reason to handle the SizeChanged event is to see whether the ratio of an element's ActualHeight versus ActualWidth have changed, because of a new layout.
For example we have a Border. What the difference beetween these XAMLs?
1) Background="Transparent"
<Page
x:Class="App1.MainPage"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<Grid
Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
<Border
BorderBrush="White"
BorderThickness="2"
Width="400"
Height="400"
Background="Transparent"
PointerPressed="Border_PointerPressed"
PointerReleased="Border_PointerReleased" />
</Grid>
2) Background="{x:Null}"
<Page
x:Class="App1.MainPage"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<Grid
Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
<Border
BorderBrush="White"
BorderThickness="2"
Width="400"
Height="400"
Background="{x:Null}"
PointerPressed="Border_PointerPressed"
PointerReleased="Border_PointerReleased" />
</Grid>
Both of these borders looks identical. But what the difference?
The difference is if we set null background the Border will not support hit-testing, that's why routed events like PonterPressed will not be raised.
Conversely though, if we set Transparent background events will be raised.
To illustrate this let's write code-behind.
using Windows.UI.Xaml.Media;
namespace App1 {
public sealed partial class MainPage : Page {
public MainPage() {
this.InitializeComponent();
}
void Border_PointerPressed(object sender, PointerRoutedEventArgs e) {
Border border = sender as Border;
if (border != null)
border.Background = new SolidColorBrush(Colors.Red);
}
void Border_PointerReleased(object sender, PointerRoutedEventArgs e) {
Border border = sender as Border;
if (border != null)
border.Background = new SolidColorBrush(Colors.Transparent);
}
}
}
1) Let's use the first XAML, compile our app and run it. Try to tap inside the square. The square becomes red because the events are rised and the handlers calls.
2) Now let's use the second XAML, compile the app, run it, tap inside the square. Nothing happens because the events are not rised. The handlers are not calls.
For completeness, I found this link http://msdn.microsoft.com/en-us/library/hh758286.aspx#hit_testing explaining this rather well - see especially the second bullet point:
Hit testing and input events
Determining whether and where in UI an element is visible to mouse,
touch, and stylus input is called hit testing. For touch actions and
also for interaction-specific or manipulation events that are
consequences of a touch action, an element must be hit-test visible in
order to be the event source and fire the event that is associated
with the action. Otherwise, the action passes through the element to
any underlying elements or parent elements in the visual tree that
could interact with that input. There are several factors that affect
hit testing, but you can determine whether a given element can fire
input events by checking its IsHitTestVisible property. This property
returns true only if the element meets these criteria:
The element's Visibility property value is Visible.
The element's Background or Fill property value is not null. A null Brush value results in transparency and hit test invisibility. (To
make an element transparent but also hit testable, use a Transparent
brush instead of null.) Note Background and Fill aren't defined by
UIElement, and are instead defined by different derived classes such
as Control and Shape. But the implications of brushes you use for
foreground and background properties are the same for hit testing and
input events, no matter which subclass implements the properties.
If the element is a control, its IsEnabled property value must be true.
The element must have actual dimensions in layout. An element where either ActualHeight and ActualWidth are 0 won't fire input events.