I have a wondows form which contains a WPF control as well. When I click on the control it brings up a WPF popup control with a listbox. The goal is, when I select an item on the listbox, the windows form will be repopulated accordingly and the popup should get closed. The current implementation with SelectionChanged on the listbox works fine.
Here is the problem. The popup is big and covers some portion of the winform which contains some links. Now, when I select an item on the listbox, the popup closes after doing necessary actions, but if there is a link just below the popup (on the winform) that is under the cursor (when you selected the item on the listbox), that link is also taking the click event.
Is there any way to prevent the links getting clicked when I click on the popup? I have to close the popup though.
I think I figured this out.
SelectionChanged gets executed when we press the mouse key down and before we lift it.(Mouse key up). The popup gets closed in SelectionChanged before we lift the Mouse key. So, when we leave the mouse key, the keyUp event actually gets fired for a link on the Winform as the popup has been closed by now.
I moved the logic from SelectionChanged to PreviewMouseUp and the popup stays till I leave the mouse key and therefore the links on the Winform do not get the event. Of course, I check whether the selection has been changed or not.
Related
I'm displaying a Popup in response to a button click (popup.IsOpen = true;). The popup contains a ComboBox, and when I click an item in the combobox, one of the things the SelectionChanged event does is to hide the popup.
The Popup appears over a DataGrid that I also have on my page, and I'm finding that the mouse-click on the combobox is also being picked up by a MouseUp event that I've got on the DataGrid. Any idea what's going on?
The MouseUp Event has a routing strategy of type Bubbling. Events that use this type of strategy get passed up the chain to parent controls. Since the Popup is a child of the DataGrid, the event will "bubble" up to the DataGrid. If you would rather the event not bubble, you can try using PreviewMouseUp, which has a Tunneling routing strategy, and will "tunnel" down the chain to child controls. Here is a decent overview of Routing Strategies.
I've hit the same issue. Oddly, it doesn't happen when the code is run in the debugger - it only happens in the release version. It really seems to be a bug in WPF. Trying to catch the click and set the event to handled doesn't work.
My workaround is to, when the popup opens, to tell the control underneath to ignore the click.
My WPF application uses the Telerik RadGridView control on a few of its screens. I have a requirement that says that whenever the user clicks on a row in the RadGridView, I'm supposed to switch to another screen and display detail information about that row. I hooked up a handler to the SelectionChanged event and this works, except that nothing happens if the user clicks on the selected row a second time. This makes sense, as the selected row isn't being changed.
How can I detect a second click on the same row and have the second screen displayed?
Tony
You could just attach a handler to the MouseUp event on the GridView. Check if there are any selected cells and respond from there. This will fire even if there is already a selection.
The MouseDown event will fire on the mouse click, but before the gridview updates the selction, mouse up should fire when the selection has already been adjusted
You can also attach a handler to each individual cell in code-behind as follows
(this.GridView as RadGridView).AddHandler(
GridViewCell.MouseUpEvent,
new EventHandler<Telerik.Windows.RadRoutedEventArgs>(this.OnMouseUp));
I think you may try to achieve this through the MouseLeftButtonDown event or PreviewMouseLeftButtonDown event.
I have some buttons in a bottom toolbar of a gridpanel that control adding, and removing records from the row-editing grid.
The handlers are pretty simple: "new" button creates an instance of the model, appends to the grid and then opens a row-editor on the new row; "edit" button just opens the selected row's row-editor; "remove" destroys the record from the store and refreshes the grid view.
For some reason these buttons don't lose the focus class that gives them a border when they have the focus. Here is a picture:
In the picture both the "New" button and the "Remove" button have the focus class, when I press the "Edit" button it also keeps the focus classes even after doing a complete row-edit operation and closing the row-editor.
I did find that when I mousedown on one of these permanently "focused" buttons and then mouseup away from it and then click something else the focus class goes away.
I know that I could put a blur handler for all button components in my respective controllers but I would have thought that this functionality was built in so I am asking to see if there is something I missed somewhere in the docs.
The classes that it won't let go of are these:
x-focus x-btn-focus x-btn-default-toolbar-small-focus
This is with ExtJS 4.1.0 in FF10 on Windows 7. But I did notice similar behavior in ExtJS 4.02 and 4.07, just haven't needed to handle it until now.
I found out what it was:
At some point in the handler chain for each of these buttons the button gets disabled. When a button is disabled in ExtJS it prevents the blur event from firing.
It was necessary to disable the buttons so the solution to simply add button.blur() in the handler was the correct way to do go about it.
I'm having a problem when the Silverlight toolkit's ContextMenu is clicked while it is over a UIElement that has registered a Tap event GestureListener. The context menu click propagates to the underlying element and fires its tap event.
For instance, say I have a ListBox and each ListBoxItem within it has registered both a ContextMenu and a Tap GestureListener. Assume that clicking context menu item2 is supposed to take you to Page1.xaml, while tapping on any of ListBox items themselves is supposed to take you to Page2.xaml.
If I open the context menu on item1 in the ListBox, then context menu item2 is on top of ListBox item2. When I click on context menu item2 I get weird behavior where the app navigates to Page1.xaml and then immediately to Page2.xaml because the click event also triggered the Tap gesture for ListBox item2.
I've verified in the debugger that it is always the context menu that receives the click event first. How do I cancel the context menu item click's routed event propagation so it doesn't reach ListBox item2?
Thanks for your help!
You can get around the problem by doing the following:
In the context menu's Opened handler set LayoutRoot.IsHitTestVisible (LayoutRoot is the default name for the root UIElement) to false
In the context menu's Closed handler set LayoutRoot.IsHitTestVisible back to true
You could try adding a rectangle with a transparent background (important) over the effected area/page when showing the context menu.
I had a very similar issue, but I am using the ManipulationCompleted event as a "tap" detector as the object the ContentMenu applies to is a custom control.
LayoutRoot.IsHitTestVisible didn't work for me, perhaps because it does not apply to Manipulation events. However, it set me on the right path. I just implemented my own simple equivalent of it - I created a boolean variable bCancelManipulation in the page's scope.
In the ContentMenu's Opened event set it to True.
In the ContentMenu's Closed event set it to False.
In the ManipulationCompleted function, the first thing I do is check
if(bCancelManipulation==true) { return; }
It's kind of a hack, but it works great and is quite simple to code - it can easily be adapted to a Tap event too.
I have a problem regarding combobox dropdown. Once a dropdown is opened, if I want to move focus to other control (say a textbox), I need to click twice because on first click, the combo dropdown is closed and then on second click, the textbox gets focus. How should I fix this? Please help.
You could listen to the DropDownList.SelectedIndexChanged event, and in the event handler set focus to the next control, either by setting TextBox.Focus(), or by calling System.Windows.Forms.Control.SelectNextControl()
I think this would be 'non standard' behaviour for what its worth. Its quite normal to expect the user to tab or select the next control after using a drop down.
Edit: Sorry, in a WPF ComboBox the equivalent event is SelectionChanged, but on reflection you'd be better using OnDropDownClosed. This would mean you only move the focus specifically after using the drop down rather than just whenever the value changes.