I've got a WPF application with a ListBox in it. For this list box, I'd like to mimic the behaviour of the users control panel (since Windows Vista) -- that is: you single-click on a list item, and it's the same as double-clicking.
In Win32, I'd do this by turning on the LVS_EX_ONECLICKACTIVATE style.
In WPF, I've attempted to do this by handling the MouseLeftButtonUp event. Unfortunately, and this is odd, it sometimes picks up the wrong item.
For example, if you double-click the title bar (caption) to maximise the window, the second mouse-up occurs over the list box, and the event is raised. Similarly, if an item is partially in view, clicking on it scrolls it into view, but the mouse-up is raised against the item that's now in view, not the one clicked.
Now, again, if this was Win32 (before LVS_EX_ONECLICKACTIVATE), I'd get mouse capture on the mouse down, remember the item, and check that I had capture on mouse up.
But it's not Win32, it's WPF. How do I do single-click activation in a WPF list box?
I must admit I never stumbled across the LVS_EX_ONECLICKACTIVATE by now, but as I understood it handling "SelectionChanged" should do the trick.
Or is there a difference between double clicking on selection or activation on selection?
Related
I use Silverlight 4.0 and have got problems with ComboBox control. I want to implement a popup menu which will show and hide itself without clicking mouse. It should show when I place cursor on its region - this prt works well. Then it should hide whenever mouse pointer is placed outside of its region for a while. I implemented it with MouseEnter and MouseLeave events. My problem is ComboBox - this control behaves weirdly, in my opinion. Normally I would expect it to raise MouseEnter event when I put the cursor on it and MouseLeave when I put the mouse cursor anywhere else. The real situation is different: Whenever I click the combobox, it opens and shows the list of options, and immediately sends LostFocus and MouseLeave events. So it seems like the control lost keyboard focus and mouse pointer has been moved out of its region, while actually the combobox list of optins is open and active and has keyboard focus in it.
So the question is how can I know in my program what is happening in comboboxes? In order to correctly hide my popup menu, I need to know when the list of options in a combobox is open or closed. I can't see any events for this or any other documentation. (Wanted behavior is: If a combobox is closed, I hide my popup menu based on the position of mouse cursor. If a combobox is open, I never hide my popup menu until user either selects something in the combobox, or closes the combobox.)
Also, if you have got a good experience with a third party combobox replacement, which looks and works similarly AND raises events I need, please let me know.
MSDN has two events listed for ComboBox that you might want to look at.
http://msdn.microsoft.com/en-us/library/system.windows.controls.combobox_events(v=VS.95).aspx
DropDownClosed Occurs when the drop-down portion of the combo box closes.
DropDownOpened Occurs when the drop-down portion of the combo box opens.
I want to display a custom confirmation message box (ChildWindow) when the user selects a row in a DataGrid in Silverlight. The message box simply has 2 buttons, a yes and a no. When the user clicks No, I want to restore the previously selected item in the DataGrid. I have been able to accomplish all of that.
The problem is that when the message box appears and I click NO and I restore the previously selected item, the item that the user tried to select remains in the MouseOver visual state until I move the mouse over some other row.
Is there any known workaround for this unusual behaviour of the DataGrid, or is this perhaps a legitimate bug in the control? I have done my research and I have not found anything as yet.
Any help would be appreciated.
Thanks!
This is classic mouse enter/leave gotcha thats common in many areas of Silverlight and indeed in many other frameworks as well. The assumption is that that mouse in and out events will come in pairs but they don't when a something else hijacks the mouse events.
Thats is what is happening here the DataGridRow is simplisticly tracking mouse over using the standard mouse events. However when you show a child window while it is in the mouse over state not further mouse events go to the row. When you dismiss the childwindow the mouse is already outside the row so it still gets no events.
A possible workaround is to fiddle with the visual state of the row yourself before showing the child window:-
VisualStateManager.GotoState(someRow, "NormalSelected", false);
Not perfect but possible good enough.
I am implementing a DragDrop framework for WPF (which incidentally you can find here).
I have a problem in that when the user MouseDowns on an ItemsControl we don't know immediately if they intended to click the item to select it, or to begin a drag. If the user clicks an item and then quickly moves the cursor, another item other than the clicked item can become selected before we determine that a drag has started (especially if clicking on the item freezes the UI for a short time to load data etc).
I think this problem didn't exist in WinForms as dragging the mouse with the button held down didn't cause another item to become selected - the selection was made only on the item on which the click occurred.
In the PreviewMouseDown event I can set the e.Handled property to prevent another item becoming selected, which works fine if the user actually did intend to start a drag, but then they can't actually select the item.
Anyone know how to handle this?
Store/use the point at which they originally moused-down, and use that to resolve the item to drag.
When the WPF ComboBox is clicked and in-focus, the only interaction that occurs after that can be with the ComboBox. If anything else is interacted with, including the window functions (minimize, restore, close, resize) and any control in the window, the action is ignored and the ComboBox loses focus.
In addition, MouseEnter and MouseLeave on the window buttons are still active, but when MouseEnter on the window border(?) occurs, the mouse pointer does not change to the resize pointer. This behavior makes sense because of the ComboBox's use of the popup control. The popup control exists independently of the main visual tree and if i.e. the window moves or gets resized, the popup remains fixed floating above the main window.
I have tried using Reflector, to see what the ComboBox is doing, but I have not been able to find what I am looking for. Basically, I do not know if this behavior is coming from the window, the ComboBox, or if it has something to do with the popup. How can I solve this problem?
You're right on in your description there, the popup keeps all action focus until it itself loses focus. If you're trying to change the functionality of the ComboBox you may want to look at creating your own ControlTemplate that behaves differently and does not keep the default action of the popup control.
Hope this helps, not entirely sure what you're trying to do.
I know this question is old, but for anyone coming here looking for the answer, it is to use Mouse.Capture.
The ComboBox sets Mouse.Capture(comboBox, CaptureMode.SubTree) in OnIsDropDownOpenChanged. This ensures that all mouse events are captured by the ComboBox. When the Popup is closed Mouse.Capture(null) releases the mouse capture.
I am working a WPF application, where I have maintained a Menu Bar with Input Gestures i.e keyboard Shortcuts.
For Save As menu item, I have kept Ctrl+A as per User's requirement. It works fine as far as the focus is on the main window.
Now my problem is, suppose use has navigated in some Listbox in window, and if he presses Ctrl+A, then Select All functionality takes places for the list box and Save As dialog box does not get called (as i have done the command binding for this input gesture)
Any idea how can I avoid this? and yes, I can not change my input gesture. It has to be Ctrl+A. :)
Thanks
I think you could change the command bindings on the list box object to remove the binding for the command. Look at the ListBox.CommandBindings list.
You could also turn off Focusable on the ListBox so that it never receives keyboard commands.
You could also check out the eventing model. You could probably catch the keydown as the preview events "bubble up" from the root of the logical tree and then they are passed down from the end element down. They can be marked as handled on the way up or the way back down.