WPF RoutedEvents Being Handled By...? - wpf

I have a 3D application in WPF which basically is supposed to zoom in and out as the MouseWheel event is fired. I have attempted to subscribe everything possible, but can't find what it is which is handling it.
Is there a way to find out what is? Or is there a way to have the event not handled, or for an encompassing UIElement to get to this event before/after the one dealing with it?

If you want to get called even though someone else has already handled the event, try subscribing to the event using the UIElement.AddHandled(RoutedEvent, bool) function. Pass in true as the second argument to get called even if the event has been handled.
You can also try subscribing to the PreviewMouseWheel event to get called when the event is tunneling.

Related

Call Methode from Event in XAML

Is it possible to have a UserControl with an Event (Event GoUp) that calls a Methode in an second Usercontrol (Sub Upgoing), and all this in WPF/XAML?
<controls:Joystick/> <!--with Event GoUp-->
<controls:TV/> <!--Sub Upgoing that should be called when Event GoUp is fired-->
I know how to solve this in Code Behind or ViewModel, but it is possible in XAML??
The short answer to your question is no. You cannot call methods in pure XAML.
You may hook up event handlers in XAML, but you'll still need to implement the event handler programmatically.
Also, if Joystick and TV are siblings in the element tree, an event raised from one of them won't bubble up or tunnel down to the other. A routed event either travels up or down, not sideways.

See what handled a routed event

Basically we have a huge project, and we have an event handler that sometimes is triggered and some others it isn't. I think this is because somewhere in the jungle of code, we're handling that event, so it doesn't bubble up to where we need it. Is there anyway to find out where is it being handled?
Thanks!
Did you try to use Snoop..... there is an event Tab that tells us where the event is bubbled to and where its handled...

No ManipulationCompleted event in Surface Toolkit for Windows Touch Beta

I am using Surface Toolkit for Windows Touch Beta. I have a UserControl within a ScatterViewItem on a ScatterView. I want to receive ManipulationCompleted event on a UserControl but it doesn't seem to ever be raised even though IsManipulationEnabled="True" is also set. The same thing works perfectly in a non-Surface WPF4 app.
It appears various Touch WPF events play well with Surface but it seems like a lot of work to recreate a tap event and NSWE events that I can easily interpret from ManipulationCompleted event.
I am looking on ways to either receive ManipulationCompleted event on my UserControl or to simulate it by handling existing touch events.
Any pointers?
does the scatterviewitem move when your usercontrol is touched? only one element at a time can be tracking manipulations for a given touch. if the scatterviewitem is getting the manipulation events, that means your user control will not.
if you only want your usercontrol to handle the input, then have it listen to TouchDown and call usercontrol.Capture(touch). if you want to have the SVI do it's thing but also handled the completed event on your own, then you will have to register your event handler manually: usercontrol.AddHandler( ManipulationCompletedEvent, yourHandler, true). the last parameter says you want to handle the event even if SVI already has.

WPF: How to delay event firing defined in XAML?

In WPF, you can define an event handler in XAML (e.g. ComboBox's SelectionChanged), which is great. However, the problem I oftern run into is that the event is fired too early. It is wired up when the control is just created. As a result, if another control below that code is referenced in the event handler, you would get null exception. I ended up with a lot of null checks in my event handler which would be unnecessary otherwise. I would like to have all events hooked up after all controls are created (e.g. OnInitialized). Is there a way to do it? Or did I miss something here?
I think the best solution is to define these event handlers in code-behind yourself, after the InitializeComponent() call in the constructor. Of course this will not be XAML anymore, but it's the only way to ensure that all controls your handlers may reference have been already created.
You can check your main control's IsLoaded property at the beginning of your event handler, and return if it's false. So when it is true you'll be confident that everything is created and ready for interaction.

Events routing in WPF

I have implemented a UserControl. Then I would like to handle an event that is originally handled by Window (keyboard press). What is the best way to route the event caught by another component (higher in the components' tree)?
Thanks in advance for the replies and hints!
Cheers
It depends on the event you're trying to access. If it's a Preview event and the Window is setting e.Handled to true you'll need to use the method Alex suggests to circumvent the Window's handling of the tunneling. If it is a bubbling event (i.e. KeyDown) you don't need to do anything special since bubbling events hit the handlers on child elements first and go up the visual tree so the Window handler won't occur until after your UC's.
One thing you need to be careful with using Key events is that the event is only going to get picked up by your UC in the first place if the Focus is on or inside of it. This isn't something you need to worry about with things like Mouse events since they start at a specific location in the tree.
I believe you cannot gurantee that.
Window class is wrapping Win32 message-based event model and this will be the only WPF entity which will have access to those information.
I suggest that you create an attached property (which will be used by the Window) and implement the routing of the events yourself so that controls could subscribe to.
You can attach the routed handler specifying that you want to handle handled messages as well:
this.AddHandler(routedEvent, handler, true);
where this is an UIElement or derived class.
However there may still be events (key presses in this case) which don't make it past the window, not sure.

Resources