My goal is to implement a custom Control + S key press handler to wire up to a custom save method in a winforms app.
There are several ways to accomplish this based on my R&D. First, I tried the obvious KeyPress event handler. This wasn't powerful enough to capture the key presses I need (it wasn't called on the Editor level, which is what I needed).
The second option which looks better is the protected override bool ProcessCmdKey(ref Message msg, Keys keyData) override. This works - it intercepts the CTRL key click, but apparently I need to write extra code to persist the fact the CTRL key is pressed and intercept the next key press (which would be S in my case) and then perform the custom action.
protected override bool ProcessCmdKey(ref Message msg, Keys keyData)
{
if (keyData == (Keys.S | Keys.Control))
{
// This is never called
}
else if (keyData == (Keys.Menu | Keys.Alt))
{
// this is called each time I hit CTRL
}
return true;
}
ProcessCmdKey seems to be called immediately after I hit the CTRL key.
This post suggests creating a KeyTracker class that will persist the keys pressed and do what it needs to do:
Capture Key Sequence via ProcessCmdKey
Which seems like a good option, but before I dig in an implement a memento tracking pattern, does anyone have input on how else to accomplish this seemingly common feature?
Another pattern uses the GetKeyboardState API function:
Capture multiple key downs in C#
This seems interesting, though I'm not sure it will suite my needs.
[DllImport ("user32.dll")]
public static extern int GetKeyboardState( byte[] keystate );
private void Form1_KeyDown( object sender, KeyEventArgs e )
{
byte[] keys = new byte[255];
GetKeyboardState (keys);
if( keys[(int)Keys.Up] == 129 && keys[(int)Keys.Right] == 129 )
{
Console.WriteLine ("Up Arrow key and Right Arrow key down.");
}
}
Thank you for taking a look at my problem.
UPDATE
I've added three events for key handling to my DataPanel. None of these events are being picked up by VS when I set breakpoints in the events, so this is what leads me to believe that ProcessCmdKey is my best option.
If I could get these Events to work, that would be good as well:
// Ctrl + S: Save Support
this.ParentForm.KeyPreview = true;
this.KeyPress += new KeyPressEventHandler(DataPanel_KeyPress);
this.KeyDown += new KeyEventHandler(DataPanel_KeyDown);
this.PreviewKeyDown += new PreviewKeyDownEventHandler(DataPanel_PreviewKeyDown);
None of these events seem to be caught when pressing any keys:
void DataPanel_PreviewKeyDown(object sender, PreviewKeyDownEventArgs e)
{
if (e.KeyCode == (Keys.S | Keys.Control))
{
SessionManager.Trace.AddTrace("You Hit Save!!");
}
}
void DataPanel_KeyDown(object sender, KeyEventArgs e)
{
if (e.KeyCode == (Keys.S | Keys.Control))
{
SessionManager.Trace.AddTrace("You Hit Save!!");
}
}
void DataPanel_KeyPress(object sender, KeyPressEventArgs e)
{
var key = e.KeyChar;
}
UPDATE
I've solved the problem by using a simple KeyUp event and the KeyPreview flag:
void ShipmentDataPanel_KeyUp(object sender, KeyEventArgs e)
{
if (e.Control && e.KeyCode == Keys.S)
{
MessageBox.Show("Control + S Key Hit!");
}
}
Thank you.
Set the KeyPreview property of our form to true. The summary of this property says: "Gets or sets a value indicating whether the form will receive key events before the event is passed to the control that has focus.". Then use the KeyUp event. Unless KeyPressed it gives also information on special keys like control keys.
I solved this by doing,
if(e.KeyData==(Keys.S | Keys.Control))
Though this is a very old question, I still like to add my answer.
The OP writes that he could not use the ProcessCmdKey because it would fire as soon he hits the Control key and would not wait until he hits the S key also.
I don't have that problem, my code below works well and the Delete() method is only called when I first hit Ctrl and then S
protected override bool ProcessCmdKey(ref Message msg, Keys keyData)
{
bool bHandled = false;
// switch case is the easy way, a hash or map would be better, but more work to get set up.
switch (keyData)
{
case Keys.F5:
RefreshList("", "", false); // call my refresh method
bHandled = true;
break;
case Keys.S | Keys.Control: // call my delete method
Delete(false);
bHandled = true;
break;
default:
base.ProcessCmdKey(ref msg, keyData);
break;
}
return bHandled;
}
protected virtual void Delete(bool handled)
{
if (handled == false)
{
MessageBox.Show("delete");
}
}
Related
I got the following sticky note example:
If the sticky note has more than 9 rows, the additional rows are not visible.
I'm able to navigate through the note with my arrow keys. If I'm going to scroll with the mouse wheel, it seems to ignore the popup and just changes the page.
Is it possible to activate scrolling for sticky note popups?
Edit:The solution outlined below will soon be available as part of the samples included in the PDFTron SDK download. In the meanwhile, I hope that the below solution helps.
Yes, it is possible to activate scrolling for sticky notes.
The problem is most apparent when using the single page view. It appears to work as expected in continuous mode.
However it is not as simple as setting VerticalScrollVisibility = ScrollBarVisibility.Auto;. There are a few files that need to be modified to get this working.
The good news is that we can get the expected behaviour by modifying the code in the provided samples.
Solution
The solution is to add some handling for the PreviewMouseWheel event coming from the PDFViewWPF class.
In the downloaded samples, the following changes were made to get things running as expected:
Add a method to handle the PreviewMouseWheel event in the NoteHost class (Samples/PDFViewWPFTools/CS/Utilities/NoteHost.cs)
internal void HandlePreviewMouseWheel(object sender, MouseWheelEventArgs e)
{
var originalSource = (UIElement)e.OriginalSource;
if (originalSource.IsDescendantOf(mNoteBorder) && mTextBox.IsFocused)
{
mTextBox.ScrollToVerticalOffset(mTextBox.VerticalOffset - e.Delta);
e.Handled = true;
}
}
Also make sure to add mTextBox.VerticalScrollBarVisibility = ScrollBarVisibility.Auto; in the NoteHost.CreateNoteAndArrow() method, after the mTextBox object is instantiated (~line 183).
Next, edit the NoteManager class - Samples/PDFViewWPFTools/CS/Utilities/NoteManager.cs - and add a HandlePreviewMouseWheel method. This will internally call the HandlePreviewMouseWheel on each displayed (opened) note and break at the first one where the event gets handled.
internal void HandlePreviewMouseWheel(object sender, System.Windows.Input.MouseWheelEventArgs e)
{
foreach(var note in mActiveNotes)
{
note.Value.HandlePreviewMouseWheel(sender, e);
if(e.Handled)
{
break;
}
}
}
Next, edit the ToolManager class to ensure that the note manager gets a chance to handle the PreviewMouseWheel before attempting a page change. Open Samples/PDFViewWPFTools/CS/ToolManager.cs and navigate to the PDFView_PreviewMouseWheel. The existing method should look like this:
private void PDFView_PreviewMouseWheel(object sender, System.Windows.Input.MouseWheelEventArgs e)
{
if (mCurrentTool != null && _IsEnabled)
{
ToolManager.ToolType prev_tm = mCurrentTool.ToolMode;
ToolManager.ToolType next_tm;
while (true)
{
mCurrentTool.PreviewMouseWheelHandler(sender, e);
next_tm = mCurrentTool.NextToolMode;
if (prev_tm != next_tm)
{
mCurrentTool = CreateTool(next_tm, mCurrentTool);
prev_tm = next_tm;
}
else
{
break;
}
}
}
}
Replace it with the below code:
private void PDFView_PreviewMouseWheel(object sender, System.Windows.Input.MouseWheelEventArgs e)
{
if (mCurrentTool != null && _IsEnabled)
{
ToolManager.ToolType prev_tm = mCurrentTool.ToolMode;
ToolManager.ToolType next_tm;
while (true)
{
mNoteManager.HandlePreviewMouseWheel(sender, e);
if (!e.Handled)
{
mCurrentTool.PreviewMouseWheelHandler(sender, e);
next_tm = mCurrentTool.NextToolMode;
if (prev_tm != next_tm)
{
mCurrentTool = CreateTool(next_tm, mCurrentTool);
prev_tm = next_tm;
}
else
{
break;
}
}
else
{
break;
}
}
}
}
By doing the above, we are giving the NoteManager a chance to handle the PreviewMouseWheel before doing anything else with it.
Another point to note is that we have to now "do the scrolling" in code, using the mTextBox.ScrollToVerticalOffset method in the NoteHost class.
Is there a way in Windows Form to activate the currently focused button/control with the Q key? Or override the Enter, so that pressing Q activates the currently focused control like Enter does? I want the user to be able to control the application with just the left hand on Tab and Q to cycle controls and activate them.
private void Form2_KeyDown(object sender, KeyEventArgs e)
{
if (e.KeyCode == Keys.Q)
{
e.Handled = true;
}
I already have this, but what do I need after the e.Handled to activate the current focus?
As an option you can override ProcessCmdKey and check if the key is Q then send Enter using SendKeys.Send and return true to indicate you that you processed the key:
protected override bool ProcessCmdKey(ref Message msg, Keys keyData)
{
if (keyData == Keys.Q)
{
SendKeys.Send("{Enter}");
return true;
}
return base.ProcessCmdKey(ref msg, keyData);
}
You can limit the behavior to buttons by checking this.ActiveControl is Button if you need.
I have WPF application which is having tool bar. In tool bar I have some user controls as tools.
I have set access key to each control, it is working fine.
The issue is: If I click a user control(which is consist of Button and Label, I have set access key for Button) the given task is completed, but when I press any access key without pressing 'Alt' key then it is getting selected.
Any ideas?
Apparently, this was a deliberate change by Microsoft. See Atanas Koralski's answer here:
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/14f6f49f-0027-471b-b68c-e7f6ba012012
Menu and ToolBar mnemonics work without pressing Alt key. We decided
that we will have uniform behavior in all cases so access key work
without pressing Alt key.
I understand that this is not in parity with Forms and we will
consider this issue and change the behavior in the next version.
For now as a workaround you can register a class handler for all
AccessKeyPressed events and handle the event if Alt key is not
pressed.
EventManager.RegisterClassHandler(typeof(UIElement),
AccessKeyManager.AccessKeyPressedEvent,
new AccessKeyPressedEventHandler(OnAccessKeyPressed));
...
private static void OnAccessKeyPressed(object sender, AccessKeyPressedEventArgs e)
{
if (!e.Handled && e.Scope == null && (e.Target == null || e.Target == label))
{
// If Alt key is not pressed - handle the event
if ((Keyboard.Modifiers & ModifierKeys.Alt) != ModifierKeys.Alt)
{
e.Target = null;
e.Handled = true;
}
}
}
Also see mfc2wpf's reply:
I've used the above and it works. However, that prevented the default
action for Enter and ESC. So I inserted the following at the top of
the method.
if (Keyboard.IsKeyDown(Key.Enter) || Keyboard.IsKeyDown(Key.Escape)) return;
Access keys include Enter and Esc, which are the default keys for Buttons which have IsDefault = true or IsCancel = true. If you don't want to require Alt+Enter and Alt+Esc for those buttons, you would need to add the special condition to the handler.
As of .Net 4.5 you can configure this behavior with the CoreCompatibilityPreferences.IsAltKeyRequiredInAccessKeyDefaultScope property. To change the access key behavior so that they will only fire when Alt is pressed set it to true.
CoreCompatibilityPreferences.IsAltKeyRequiredInAccessKeyDefaultScope = true;
As the documentation states this must early in the app. Setting it will throw an exception after it has been read.
As stated in other answers, setting IsAltKeyRequiredInAccessKeyDefaultScope avoids invoking actions for access keys without pressing the Alt key. However, this can also have the effect of disabling the Enter key (for invoking the default action) and Esc key (for invoking the Cancel action).
Using the suggested workaround instead, and testing for Key.Enter and Key.Escape, can circumvent this problem. However, you might then find that menu items cannot be selected by their access key without pressing the Alt key, which could be a problem if a button in scope uses the same access key.
An alternative could then be to handle the access key event by checking whether a potentially invokable AccessText control is within a MenuItem or not, something along these lines:
EventManager.RegisterClassHandler(
typeof(UIElement),
AccessKeyManager.AccessKeyPressedEvent,
new AccessKeyPressedEventHandler(OnAccessKeyPressed));
...
static void OnAccessKeyPressed(object accessKeyTarget, AccessKeyPressedEventArgs e)
{
if (!e.Handled && e.Scope == null &&
(Keyboard.Modifiers & ModifierKeys.Alt) != ModifierKeys.Alt &&
!ShouldElementHandleAccessKeysWhenAltIsNotPressed(accessKeyTarget as UIElement))
{
e.Target = null;
e.Handled = true;
}
}
static bool ShouldElementHandleAccessKeysWhenAltIsNotPressed(UIElement element)
{
if (element == null) return false;
var accessText = element as AccessText;
if (accessText != null && !IsDecendantOfMenuItem(accessText)) return false;
return true;
}
static bool IsDecendantOfMenuItem(DependencyObject element)
{
for (; element != null; element = VisualTreeHelper.GetParent(element))
if (element is MenuItem) return true;
return false;
}
Is it possible to define key bindings in WPF for a sequence of key presses like the shortcuts in Visual Studio e.g. Ctrl + R, Ctrl + A is run all tests in current solution
As far as I can see I can only bind single key combinations like Ctrl + S using the element. Can I bind sequences using this or will I have to manually handle the key presses to do this?
You need to create your own InputGesture, by overriding the Matches method.
Something like that:
public class MultiInputGesture : InputGesture
{
public MultiInputGesture()
{
Gestures = new InputGestureCollection();
}
public InputGestureCollection Gestures { get; private set; }
private int _currentMatchIndex = 0;
public override bool Matches(object targetElement, InputEventArgs inputEventArgs)
{
if (_currentMatchIndex < Gestures.Count)
{
if (Gestures[_currentMatchIndex].Matches(targetElement, inputEventArgs))
{
_currentMatchIndex++;
return (_currentMatchIndex == Gestures.Count);
}
}
_currentMatchIndex = 0;
return false;
}
}
It probably needs a little more than that, like ignoring certain events (e.g. KeyUp events between KeyDown events shouldn't reset _currentMatchIndex), but you get the picture...
The answer by #ThomasLevesque is mostly correct, but doesn't deal with repeating keys. (Note that holding the Ctrl key down causes key-repeat events to be generated.) It can also be useful to time out if the user stalls mid-sequence. Here's what I'm using:
public class MultiKeyInputGesture : InputGesture {
private const int MAX_PAUSE_MILLIS = 1500;
private InputGestureCollection mGestures = new InputGestureCollection();
private DateTime mLastWhen = DateTime.Now;
private int mCheckIdx;
public MultiKeyInputGesture(KeyGesture[] keys) {
Debug.Assert(keys.Length > 0);
// Grab a copy of the array contents.
foreach (KeyGesture kg in keys) {
mGestures.Add(kg);
}
}
public override bool Matches(object targetElement, InputEventArgs inputEventArgs) {
if (!(inputEventArgs is KeyEventArgs)) {
// does this actually happen?
return false;
}
DateTime now = DateTime.Now;
if ((now - mLastWhen).TotalMilliseconds > MAX_PAUSE_MILLIS) {
mCheckIdx = 0;
}
mLastWhen = now;
if (((KeyEventArgs)inputEventArgs).IsRepeat) {
// ignore key-repeat noise (especially from modifiers)
return false;
}
if (!mGestures[mCheckIdx].Matches(null, inputEventArgs)) {
mCheckIdx = 0;
return false;
}
mCheckIdx++;
if (mCheckIdx == mGestures.Count) {
mCheckIdx = 0;
inputEventArgs.Handled = true;
return true;
}
return false;
}
}
I'm using this by defining the RoutedUICommand in XAML:
<Window.Resources>
<RoutedUICommand x:Key="MyCommand" Text="My Command"/>
</Window.Resources>
This is referenced from <Window.CommandBindings> and <MenuItem> as usual. Then, in the window constructor, I do:
RoutedUICommand ruic = (RoutedUICommand)FindResource("MyCommand");
ruic.InputGestures.Add(
new MultiKeyInputGesture(new KeyGesture[] {
new KeyGesture(Key.H, ModifierKeys.Control, "Ctrl+H"),
new KeyGesture(Key.C, ModifierKeys.Control, "Ctrl+C")
}) );
I found this forum post helpful.
You will need to add an explicit InputGestureText to any MenuItem, unless you want to try the DisplayString hack in the linked forum post.
NOTE: the key gesture handler "eats" the key that completes the gesture. If you have more than one handler, and the user tries to use two multi-key sequences in a row (e.g. Ctrl+H, Ctrl+C followed immediately by Ctrl+H, Ctrl+D), the second handler won't reset when Ctrl+C is hit. Instead, it'll reset when the second Ctrl+H arrives, and will miss the combo. The actual behavior is dependent upon the order in which the handlers are called. I'm currently handling this by defining a static event that fires when a match is found, and subscribing all instances to it.
Update: one other thing to be aware of: the order of items in <Window.CommandBindings> matters. If you have a Copy handler that fires on Ctrl+C, it must appear in the list after the multi-key gesture for Ctrl+H, Ctrl+C.
<KeyBinding x:Name="mykeybinding" Gesture="CTRL+P" Key="E"
Command="mycommand"/>
That seems to do trick at my end, I have have to press ctrl+P+E to execute "mycommand"
Based on
http://msdn.microsoft.com/en-in/library/system.windows.input.keybinding.aspx
My WPF application has behaviour triggered by the functions keys (F1-F12).
My code is along these lines:
private void Window_KeyDown(object sender, KeyEventArgs e)
{
switch (e.Key)
{
case Key.F1:
...
case Key.F2:
...
}
}
This works for all F-keys except F10. Debugging, I find that e.Key == Key.System when the user presses F10.
In the enum definition, F10 = 99 and System = 156, so I can rule out it being a duplicate enum value (like PageDown = Next = 20).
So, how do I tell when the user presses F10?
Is it safe to check for Key.System instead? This feels a little dirty - might it be possible that Key.System would ever result from some other key being pressed? Or is there some setting somewhere that will make F10 report as Key.F10?
In addition to Yacoder's response, use the following to check for the F10 key:
case Key.System:
if (e.SystemKey == Key.F10)
{
// logic...
}
The SystemKey property will tell you which System key was pressed.
F10 launches the window menu. It's the same in all Windows apps.
It seems that Key.System is the expected value for the F10 key.
Answer with DataContext:
public partial class BankView : UserControl
{
public BankView()
{
InitializeComponent();
this.KeyDown += new KeyEventHandler(BankView_KeyDown);
}
private void BankView_KeyDown(object sender, KeyEventArgs e)
{
try
{
switch (e.Key)
{
case Key.F4:
((BankViewModel)DataContext).OpenAccount();
break;
}
}
catch (Exception ex)
{
...
}
}
This worked for me, for F1
Private Sub Window_KeyDown(sender As Object, e As KeyEventArgs) Handles Me.KeyDown
If (e.Key = Key.F1) Then
ShowHelp()
End If
End Sub