What is the difference between OnLoad method and Load event? I am developing WinForm controls.
Should I register to Load event or override the OnLoad method? What are the advantages and the disadvantages of each one?
I'd go for overriding OnLoad, so you spare the CPU cycles to invoke the event handler.
The general pattern is to override a method, if you inherit from a control; otherwise, subscribe to the event.
But remember to call the base class' OnLoad method, because that's where the Load event invoked.
OnLoad method is the one that raises Load event. It's a standard pattern in framework classes, and a generally recommended one - for any event Foo, you have a virtual protected method OnFoo which raises that event; and no other method of the class raises the event directly, but always calls OnFoo.
If you need to handle the event on this, it's usually both easier and faster to override OnFoo.
OnLoad is the default event handler used in VB.NET to handle the Load event. I typically override this method when I need to attach code to the load event. There are also default functions for the other Page Life Cycle events: OnPreRender, OnInit, etc.
Just to add a bit of clarity to the existing answers, an event handler is something that 'waits' for the event to trigger. This requires some CPU overhead as you need to have a thread 'listening' for the event to occur. This would be something like MainWindow_Load() in a winforms application. However, since we already know 'when' the event will happen (it happens as soon as the form loads), there's no reason to actually use an event handler. It's not like a click event where we have no clue when the user might click in which case you really do need an event handler. So instead of holding up some CPU processing, we can create a method in the class which simply forces the Load event to occur which is called invoking the Load event.
This is why it's preferable to use the OnLoad method when possible, in situations where you always know when the event is going to happen.
Related
When I try to add Nokia Ad Exchange ad control in my page XAML, the overridden OnManipulationStarted event handler doesn't fire when I touch it. It is fired if I touch anything else, but if I touch it specifically, then it doesn't enter in the method code.
Is this a related issue to the control or should I add something else?
It's probably handled by the control, so it doesn't bubble up.
You can use the alternative control.AddHandler method rather than += to add an event handler. It takes a boolean that specifies if you want the event handler called even if it was handled by a sub-element.
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.