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.
Related
I would like to have a clear explanation about how to determine in each situation which control is the sender and which one is the source for a WPF Routed Event event both in the case of tunnelling and bubbling events.
Edit:
Suppose you have an event handler and two controls one child of the other. The handler is in the parent control. How would I know beforehand and without debugging which control is passed as the sender and which one as the e.source? And does this change when you consider bubbling or tunnelling events?The general concept of events is clear to me, but I would like to understand which parameter to use in the eventhandler to indentify both controls without debugging
There probably isn't an exhaustive "clear explanation", because there are so many ways you could end up with events. Especially when a lot of events use EventArgs.Empty, because there are no other details, other than the source.
http://msdn.microsoft.com/en-us/library/17sde2xt(v=VS.100).aspx
or, more specificly:
RoutedEvent: Source vs. OriginalSource
Do you have a specific question you need answered?
Edit: from the above linked article, with an answer similar to your comment
Consider a custom control (called CustomControl1 in this example) that is composed of a TextBlock.
When a MouseDown event is raised on the TextBlock, the OriginalSource property will be the
TextBlock, but in CustomControl1's handler, the Source will be changed to the CustomControl1
object so that other elements along the event's route will know that CustomControl1 received a
MouseDown.
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.
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.
I have several controls on my form and on changed event the logic entity properties are changed. Is it possible not to implement changed event for every control,but do it in one place and update my logic entity when user is making changes on the form?
You need to subscribe to Change event of every control, but use the same event handler for all controls. For example, all textboxes can subscribe to the same Change event handler. For other control types, event handlers may have different types, so you can write one event handler per control type. You can also write single function, like OnUpdate, and call it from all event handlers.
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.