I have code written on my Listbox mouse double click. I have a submit button too in my form . On mouse double click i want a mouse double click event to be fired first and then the button click
Is it possible?
Please reply
Thanks
Sharath
Easiest (and best practise) is simply to put the code for what to do on Button click into a seperate method (say OnOkClicked), then call this method from the Button Click event handler, as well as at the end of the ListBox DoubleClick event handler.
I nice pattern to implement is to implement an ICommand (like Josh Smith's RelayCommand - google it) on your modelview class, bind the button's Command property to it, and then in the list box's DoubleClick handler, invoke the Executed method of the command. This strucutre simplifies maintaining the logic of:
If nothing is selected in the list box, disable the OK button (Command.CanExecute would return false)
If something is selected in the list box, enable the OK button
If the list box is double clicked, select an item and invoke the OK command.
Hope this helps.
you can make your own control and implement ICommandSource which will give you the same properties
Related
I have a telerik gridview that I need to add both a single click and double click event. Basically the user can click a row once for a distinct event and then can also double click for a different event.
Initially I was using the SelectionChanged event to differentiate the two... but now I am having issues with anytime anything changes on the page, this event is fired.
If I implement a single click (MouseDown) event and a MouseDoubleClick event. The single click always overrides the double click and it cannot distinguish between the two - thus never making it to the double click event.
If you're using MVVM, you would probably prefer to attach an ICommand, which will be passed the DataContext of the row that has been clicked on, as a parameter.
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.