I've created a custom panel control and would like to have it respond to a mouse move event, however, when I add an event handler like so:
Private Sub FloatingPanel_MouseMove(ByVal sender As Object,
ByVal e As MouseEventArgs) Handles Me.MouseMove
End Sub
It only responds when I move the mouse over one of the child controls within the panel. I need to have it respond whenever I move the mouse anywhere inside the custom panel.
Update:
I found the following question which gave me a clue:
WPF - how to best implement a panel with draggable/zoomable children?
I can get mouse events on the
GraphCanvas itself only if it has a
background at the point
This led me to simply set the background which appears to have resolved the issue... My question now is, why? Why should I have to set the background in order to receive a mousemove event?
Update 2: The following code is what ultimately solved the problem (See Kent's answer below).
Protected Overrides Function HitTestCore(ByVal hitTestParameters As System.Windows.Media.PointHitTestParameters) As System.Windows.Media.HitTestResult
Return New PointHitTestResult(Me, hitTestParameters.HitPoint)
End Function
Thank you,
Matt
For the purposes of hit testing, WPF's default hit testing logic has two modes of transparency. One is transparent both visually and to hit testing (#00000000 or by not setting a background at all), the other is transparent only visually and does not preclude hit testing (##00ffffff). You want the latter.
I believe you could also override UIElement.HitTestCore in your custom Panel such that there is no dependency on having the background set.
I actually suspected this might have been the issue here; If the background of a control is null and there is no other subcomponent there your mouse is not moving across the control but accross the control behind it, so it makes sense that you do not get a mouse event from that (it is not very expected though because the bounds of the control may envelope the area).
Related
I have a Grid with a Button inside. The button has Flyout menu attached.
I implemented an action which opens the flyout menu when the button is tapped/clicked. This is the default behavior which does not require event writing. I also implemented an action when the grid is tapped/clicked.
The problem is that I do not want the grid to react when I tap/click the button. Based on this fine read, it all makes sense, but in my case, I do not have any code behind to add the e.Handled = true; line to.
Is there any way I could stop event bubbling up the tree using XAML only? Thanks!
While I hate to poach Gusdor's points. There is a built an enumeration property to deal with this types of situations called ClickMode which you can override the default mode for Button of Release and set it at the instance as ClickMode="Press" to get the desired effect and allow it to receive HitTestVisibility individually before any parent does.
Hope this helps, cheers.
I believe you will need to write some code but not the code behind you are trying to avoid.
Create an attached behavior that subscribes to, and handles the
bubbling event.
Attach the behaviour to the element where you want
the event bubbling to stop.
There is a Microsoft article about plugging Behaviours into UWP apps https://blogs.windows.com/buildingapps/2015/11/30/xaml-behaviors-open-source-and-on-uwp/
I have UserControl, which contains Canvas (in Grid).
When I just clicked on canvas event PreviewMouseLeftButtonDown or MouseLeftButtonDown works perfectly, but when I set canvas.Background = new ImageBrush(imgs); and try to click on canvas, events doesn't raising. I tried to make same events for grid (canvas parent), but result was the same.
UPD1: canvas has children - rectangle (from System.Windows.Shapes) around cursor, maybe it somehow affect on events.
In wpf there are two possible scenarios where hit testing (clicking with mouse somewhere) is not working. These two are ment to be that way and it is by design. I am talking about when your Background is NULL or when you have the property IsHitTestVisible set to false.
In any other case hit testing/clicking will work.
I assume your background is null somehow. Maybe imgs throws error which will be catched in an empty try/catch block internally at render time.
Tell us is the background property of your canvas null?
There is a nice tool called Snoop which allows you to snoop an wpf app and change properties at runtime. Use that tool to change the background and tell us about the results.
EDIT:
First of all the default value of Canvas Background is null therefore by default you can click as often you wish on Canvas and nothing will happen.
As soon you change the Background to Yellow it clicking will work and your handler will be called.
I have a little problem with my RIA-enabled SL application.
THE BACKGROUND:
The relevant part looks like this:
When any data operation (i.e. load,
submit, login etc.) is in place, then
a BusyOverlay control (which I wrote)
disables RootVisual and provides a
visual effect. When the
operation is finished, then it sets
RootVisual.IsEnabled to whatever it
was before. It works just like
ChildWindow when it comes to
interaction with RootVisual (at least
as far as I can tell).
One of the elements in RootVisual (which itself is a UserControl) is a hiding menu. It is a border which contains the actual menu. It has two storyboards in Resources (which increase and decrease it's width - nothing fancy, they are as simple as you can imagine), and the border itself has MouseEnter and MouseLeave handled. The handlers start one of the storyboards, just one line of code. I don't provide any samples because there is nothing interesting going on, it would just bloat the post. If you think it is necessary, just tell me and I'll post the relevant XAML and C# code.
THE PROBLEM:
When the RootVisual is disabled, then the Border.MouseLeave event does not fire. When user clicks something in the menu that loads initial data, and then moves the mouse outside the menu, it does not hide. Is there any way to elegantly solve this problem? CaptureMouse is out of question (it requires mouse left button to be down). All I can think of is to publish an "OperationFinished" event in my data operation handling static class and handle it in the UserControl which is RootVisual, but I think it's ugly and doesn't fit in my architecture. Is there something I'm missing?
I'll be grateful for any solutions and suggestions.
I think I'm going crazy...
I have Canvas with event handlers for MouseMove & MouseLeftButtonUp.
However MouseLeftButtonUp is not being fired when it happens with cursor over TextBlock that is inside canvas.
(it fires just fine when I release mouse button in empty space of the canvas)
I tried attaching handler via AddHandler and using regular += syntax, nothing seems to work.
I tried using Canvas.CaptureMouse() but it doesnt seem to work either (CaptureMouse returns true btw).
MouseLeftButtonUp just doesnt want to propagate to it's parent when it happens over TextBlock (or any other element with IsHitTestVisible = true) inside Canvas.
Please help.
First I'd like to say that you are not going crazy. I've seen this before in Silverlight applications. Silverlight has some interesting event strategies. Silverlight events follow a bubble up approach for routed events but not with all events (msdn has some information on this) The events you are listening to are in that list but they are being handled by the TextBlock. Most UIElements have IsHitTestVisible=true so that mouse events and others are captured by the control and not bubbled up to its parent. Setting IsHitTestVisible=false should solve the problem. Other than that I can tell you what I have tried to overcome this issue when needing IsHitTestVisible=true.
Set the event hanlder from the parent on the TextBlock. Downside is you need to do this for every control in your canvas.
Try to fire the event through an extension class. I could not get this one to work cause i couldn't fire events using reflection.
You mentioned you tried AddHandler - did you try the AddHandler overload that accepts two parameters, the second one being "true" to indicate you want to get handled events as well?
On System.Windows.UIElement there is a CaptureMouse() and a paired ReleaseMouseCapture() method. In this WPF DragDrop sample they call CaptureMouse on MouseDown and release it on MouseUp. The documentation in MSDN is about as useless as it comes - "CaptureMouse -> Captures the mouse."
In my head before trying it I assumed that it somehow locked the mouse inside the UIElement bounds, but that's clearly not the case when I try it. From experimenting, it seems to have something to do with responding to events when the mouse is outside of the UIElement, but not wanting to be a cargo cult programmer I don't want to just use it because the example does, I'd like an authoritative description of what it means.
From Capture and Uncapture the Mouse on MSDN:
When an object captures the mouse, all mouse related events are treated as if the object with mouse capture perform the event, even if the mouse pointer is over another object.
Only the capturing control receives the mouse events until released.
Capturing the mouse is useful for dragging because all the dragging code can exist in the one control, rather than being spread over multiple controls.
When it has captured the mouse, a control will receive mouse events even if the mouse pointer is no longer within its bounding area.
Typically, it's used for:
Drag and drop
Buttons (to handle Mouse Up when you put the mouse down on the button and move the mouse before you release the button)
The Silverlight 2 documentation for it has a more verbose description, I don't know why it isn't a part of the 3.5 documentation page too:
When an object has captured the mouse, that object receives mouse input whether or not the mouse pointer is within its bounding area. The mouse is typically only captured during simulated drag operations.
...
It works the same with WPF, and so the reason it is used with DragDrop, is that is how the
it knows to report back to the control being dragged from when the mouse may be outside of that control. If you comment out the MyCanvas.Capture() and the Capture(Null) (which clears it) then you can no longer drop.