I making a multi select list. On item click it toggles a certain class on that item. I would like to implement multiple selection while CTRL key is down.
Is this possible?
The ctrlkey property of your event will evaluate to true if the control key is down when it's called. So basically something like:
if (e.ctrlkey) {
your code
}
Update: In answer to your question in the comments, yes. The event object is pretty robust and exposes a number of properties that you can use to determine the type of event you're dealing with, how it was triggered and so on. This is a pretty decent and concise writeup on the event object: http://www.htmlgoodies.com/beyond/javascript/events-and-javascript-part-3-the-event-object.html.
Related
I am looking for something that fire before the source is update
So instead of Binding.SourceUpdated I want Binding.PreviewSourceUpdated
I think you would need to handle this on your UI element and intercept the event if it's not ideal. So for example say you had a text box and a user pressed a key. You would use the PreviewTextInput (or similar preview) to see if you wanted the data changed - then mark the event has handled if you didn't.
The only other option that I know of is to use DataValidation and not allow the property to be updated for the model side.
My AutoCompleteBox calls a WCF service when the selection is changed, usually with the mouse. However if the user uses the arrow keys to navigate through the selection, the event fires up for each element, making the application too much data intensive.
How do I prevent the AutoCompleteBox_SelectionChanged to fire when the keys are pressed?
I found this which sounded like a nice solution but it doesn't work http://betaforums.silverlight.net/forums/p/137710/307786.aspx
ok, rather than using AutoCompleteBox_SelectionChanged, I'm using AutoCompleteBox_DropDownClosed, and this fixed the problem.
I just found how I have solved this same problem. Also I am not using SelectionChanged.
I added behavior to item DataTemplate (to Grid root). This behavior attach click handler to item. When keys are used, behavior is "sleeping", when I click on item with mouse, behavior get called and make its work. (Also I bind needed property of item to a DataTemplate's Grid's Tag property, so I can get to it from behavior)
Not suitable for every solution, but can be useful.
I need to respond to keydown events (O, C, G keys etc., not modifier keys) while a Drag+Drop operation is in progress over my control (i.e. between DragEnter and DragLeave). However the KeyDown event is not called at this stage.
I've tried selecting my control and specifically setting focus on DragEnter, but that doesn't work.
EDIT:
Hans' answer is basically correct, except I had to use GetAsynchKeyState to get the behaviour I wanted.
The QueryContinueDrag event is raised on the drag source. Checking for the state of the keys you are interested in is going to require pinvoke, the event is only designed to help recognize the Escape key and modifier key state changes. Which is something to keep in mind, that these keys have any special action is very undiscoverable.
[DllImport("user32.dll")]
private static extern short GetKeyState(Keys key);
It returns a value < 0 when the key is down. I can't say it's guaranteed to work correctly but it looked good when I tried it.
You can also try:
Keyboard.IsKeyDown(); method to check if a specific key is pressed, i.e.:
bool isKeyPressed = Keyboard.IsKeyDown(Key.LeftAlt);
It's similar to the previous answer, but it's a native .NET method, so it doesn't require you to import any functions.
A similar question has been asked here: Handle KeyDown during a drag drop. Or keydown event not workign, but there was a suggestion to make it work like an event.
UPDATE
The first solution seems to work only in WPF. If you want to check states of modifier keys, there is, however, a method utilizing a property Form.ModifierKeys that should work correctly in WinForms. The example shows how to check if alt (left alt) and ctrl keys are both pressed:
if (Form.ModifierKeys == (Keys.Alt | Keys.Control))
{
//TODO: insert your code here
}
What are some of the practical differences between using the CollectionViewSource.View.Filter property as opposed to the CollectionViewSource.Filter event? Are there situations where you would use one over the other or is it a matter of preference?
Cheers,
Berryl
EDIT:
I do see that the docs say "If your view object comes from a CollectionViewSource object, you apply filtering logic by setting an event handler for the Filter event." although nothing stops you from setting the property on the view, and it doesn't say why to do so.
The advantage I have found so far in setting the event on the CollectionViewSource is that you can implement all of your filtering logic in one event handler and then use View.Refresh (or View.DeferRefresh) to invoke it as the user changes filtering criteria.
Setting the Filter event in the CollectionViewSource would mean that the event is called even when there is no filtering needed which would make the process less efficient.
The official way of using the Filter event is by adding it on filtering and removing it later when the filter is cleared.
viewsource.Filter += viewsource_Filter;
Then:
viewsource.Filter -= viewsource_Filter; //how do you know how many events there are!?
If you use the event, you have to make sure that you are not adding the event each time the filter value changes, because apart from having redundant events lurking around (=app works harder for nothing) you will have to remove all the events in order to clear the filter.
Thus, there is an advantage in using the Filter property, because you can more easily clear the filter by setting the property to null.
viewsource.view.Filter = null;
I have a question regarding a ComboBox in silverlight and it's selected item.
I would like to determine what triggered the SelectionChangedEvent, was it the user selecting a new item in the list or was it programatically set?
While ideally I would like to solve this using the CommandPattern (I am essentially using a modified RelayCommand (http://joshsmithonwpf.wordpress.com/2008/11/17/emulating-icommandsource-in-silverlight-2/). I am open to other suggestions.
I have also played around with the SelectionChangedEventArgs, which has an OriginalSource property, which upon first inspection may appear to help, however it is null (regardless of the manner in which the item was selected.)
Any ideas, other than setting an internal flag? :)
Thanks
Unfortunately this is a tough thing to determine, since the framework works pretty hard to simply bubble up any changes or user events in this situation as that selection changed event.
If you really need to, you could write a simple ComboBoxWrapper that is effectively the flag you're talking about - so you could derive from ComboBox, try overriding or hiding the CLR setter for SelectedItem, and then maintain state that way.
Any particular scenario in use here? There may be another way to approach a solution.