I want to handle MouseEnter event for a Custom Control when control is disabled.
Is there a way to handle it?
The documentation for UIElement.IsEnabled documents the behaviour you see:
Elements that are not enabled do not participate in hit testing or focus and therefore will not be sources of input events.
The logical conclusion, to me, is that if you do want to handle mouse events, you don't disable the control. Instead, use some other method of achieving what you want. For example, if it's an input control, it may be good enough to make it read-only instead of disabled. Your question doesn't really explain why you want this, so I cannot guess what the right method for you will be.
perhaps you could surround your custom control with a ContentControl (which must always be enabled) and handle MouseEnter event on the ContentControl.
Related
Ok. This seems like an incredibly basic use case but fore some reason I am having an issue finding a common solution across control types.
Heres the use case:
A form is presented to the user with any editable controls. (Text box, combo, grid etc.).
The user edits a value in the control and tabs out.
Expectation is that I can wire to an event like Lost Focus and do "foo" with the changed value.
The user then gives focus back to the control and tabs out without making an edit.
Expectation is that whatever event I am wired to I can check if the value has been changed.
Is there one common event across controls that will only fire when the user has finished editing( such as tab out or enter ) and allow me to check previous state vs. current state?
Jason, you may want to look into Binding and DependencyProperties in WPF instead of tracking events in your form. You would bind a class to your form which exposes properties to be changed. Using DependancyProperties a single event is fired called "PropertyChanged".
Unfortunately is is a broad topic, but you will really get the full benefit of the WPF programming model. Searches on "dependency properties in wpf" will give you some good examples.
I think maybe this is Focus issue. There exist two different focus types: keyboard focus and logical focus. The the control that has keyboard focus is the one that has the caret, in what the user press a key and the control process that input. The a control may have the logical focus but not having the keyboard focus. Please check this in the MSDN article "Input Overview". About the other question, maybe you could process the TabControl.SelectedItemChanged for taking the event when a tab item selection changed.
Hope this is helpful to you...
What you may be interested in is implementing INotifyPropertyChanging (not just INotifyPropertyChanged).
As noted in the answer of this question, the INotifyPropertyChangING does not prevent you from changing a value, but to detect WHEN something DOES change, and what it's new value is going to be.
Hope it helps in your solution needs.
As the previous answers suggested, you would be better off by implementing a view - viewmodel structure, with your viewmodel having implemented INotifyPropertyChanged, and thus allowing you to bind to properties that will announce their changes to the UI.
If you don't want to do this, you can eventually subscribe on your input elements to the PreviewKeyUp event, check if the Tab key has been pressed and proceed from there.
I have treeview control on a winform and need to implement onChange event for it. However, it looks like it doesn't have one and only has onChangeUI.
If the treeview doesn't support onChange event, what is its equivalent in .NET.
I've searched MSDN Library and didn't find any information.
Update: a side note I am converting win32 program for .net.
Thanks in advance,
Support for selection change is a little limited in the Windows Forms TreeView control.
Basically, there is a pair of events (BeforeSelect and AfterSelect) that allow you to react when a tree node is selected. BeforeSelect allows you to cancel the new selection, AfterSelect does not (because it occurs after the new selection has been committed).
However, none of these events are triggered when a node is unselected. To detect that case, you'll have to handle the generic MouseUp event and check the IsSelected property of the clicked node to get the actual selection state.
This is a common restriction in the wrapper classes that wrap native Windows controls. Which only generate notifications for things that you cannot know about. Like anything that the user can do that affects the control. It omits notifications for things that you do, with the underlying philosophy that you don't have to be reminded about something you already know.
Which is certainly the case for TreeView, the user cannot add any nodes. Only you can. Same thing for the text displayed in the nodes. No event to tell you the text changed. Except in the very specific case when the user edits the node, AfterLabelEdit event.
You can derive your own class from TreeView and add a Change event and OnChange() method that fires it. It is up to you to write the code to call the method. Beware that this is difficult to do reliably, the TreeNodeCollection class doesn't have virtual methods so you cannot override them to detect the client code changing nodes. You are actually better off not writing that code and simply generate an internal event in the form in any method that modifies the TreeView content.
This one is a bit tricky to explain.
I have a usercontrol with some textboxes. I also have a menu just above this usercontrol in the same window. Whenever I tab away, the LostFocus fires correctly on the textbox, and this is what I want. Strangely enough, if I click the Menu button on top of my window, the LostFocus event does not fire on the textbox. Is there an elegant way to make sure that my menu properly allows LostFocus to fire on any controls which last had focus?
I also want to avoid having to Update BindingExpressions otherwise I would likely be doing this for N textboxes, which is undesirable.
I can't imagine it is too difficult to achieve this.. I just don't understand how this doesn't work: in most other situations LostFocus always fires.
Any ideas? Thank you.
Is the menu WPF as well or Winforms / UnManaged? If either of the two then the lost focus event does not fire. This can play havoc with WPF controls as many time a save or other data function is being performed from the menu. To counter this I have had to implement multiple ways to combat this. The easiest way was to implement a mouse leave event on the user control itself and perform any actions you require manually in code.
This seems very strange to me.
I know through some adventurous inheritance you can convert most UIElements to a button, but it is a cumbersome way of implementing the most basic of of computer events
The ButtonBase class certainly has a Click event. So has derived classes.
I think the most basic events are MouseDown and MouseUp which are available to every UIElement
use RoutedEvents event if you really need to use.
Other wise use dependency property to register a Click event against your control and then do what ever you want to do.
You can add RoutedEvents to your controls.
Here is an implementation example
I've built several user controls in WPF and they all get added to a canvas. I want to add a behaviour that keep tracks of the currently selected usercontrol. A usercontrol should be selected when:
The mouse clicks on it;
when it recieve focus;
when either of the two above happens to a subcontrol of the usercontrol.
Is there any way to handle this purely by using the focus mechanism of WPF or will I need to take care of this myself with assistance of the focus classes?
I've read up upon the new way of handling focus in WPF, and the problem I'm facing is that the keyboard focus determines what the currently selected object is, but some parts of the my control can't recieve keyboard focus so even though these parts are clicked, the usercontrol doesn't recieve focus.
I'm looking for advice on how to implement this feature and how much I could/should rely on the focus mecanisms. Ultimatively I wouldn't mind if only a single object could be selected, but if it's easily extendable to multi-select then I wouldn't mind this either.
Just to clarify, I know I could build this manually by handling a lot of events and keeping track of states, but I was just hoping an easier approach was available.
Combine UIElement.IsKeyboardFocusWithin with a PreviewMouseDown handler:
When PreviewMouseDown is called, set a flag and schedule callback using Dispatcher.BeginInvoke at DispatcherPriority.Input to set focus to the UserControl if the flag is still set.
Set a handler for UIElement.IsKeyboardFocusWithin property changes in your UserControl. When the handler fires, clear the flag.
The idea here is that if you click anywhere on the UserControl and keyboard focus does not result in the focus being moved into the UserControl, force it into the UserControl.
FYI, here's roughtly what step 1 looks like in code:
public override OnPreviewMouseDown(MouseButtonEventArgs e)
{
_mouseClickedButNoFocus = true;
Dispatcher.BeginInvoke(DispatcherPriority.Input, new Action(() =>
{
if(_mouseClickedButNoFocus)
Focus();
});
}
You could use the UIElement.IsKeyboardFocusWithin property, which is true when the UIElement or one of its children has keyboard focus. It is a dependency property, so you can easily use it for a trigger in a style
You can set the logical focus to the control when any of the child gets the keyboard focus using FocusManager.IsFocusScope="True". Setting the keyboard focus to the control or trying to do will eat the keys for the child controls.
You can use UIElement.IsKeyboardFocusWithin to set the focus of the control if any of the children has focus.
You can read this article which I think describes the difference between Logical and Keyboard focus quite well:
http://www.pluralsight.com/community/blogs/eburke/archive/2009/03/18/why-is-focus-in-wpf-so-tricky-managing-and-understanding-focus-in-a-wpf-application.aspx