Strange keypress captue behavior 1

[MasterRacker]

I have a situation where I want the F5 key to append a timestamp to the contents of certain textboxes when that textbox has focus. I was expecting this to be fairly simple but...

Here's the keypress event for a box:

    private void uxNotes_KeyPress(object sender, System.Windows.Forms.KeyPressEventArgs e)
    {
      uxNotes.Text += Timestamp.F5Append(e);
    }

Here's the timestamp method:

using System;
using System.Windows.Forms;

namespace TI.Lib
{
  public class Timestamp
  {
    public static string F5Append(KeyPressEventArgs e)
    {
      if ((Keys) e.KeyChar == Keys.F5)
      {
        return "***test***";
      }
      else
      {
        return "";
      }
    }
  }
}

The surprising behavior is that I get the test string when I press "t", instead of the F5 key. What can possibley cause something like that?

[sub]Jeff
[purple]It's never too early to begin preparing for [/purple]International Talk Like a Pirate Day

I was not born cynical - I earned my cynicism through careful observation of the world around me.[/sub]

 

[earthandfire]

Function Keys are 'extended' keys, they return two bytes so your code probably just picks up the low byte.

If you trap KeyEventArgs instead of KeyPressEventArgs, you can use:

e.KeyCode == Keys.F5

which should work.

Hope this helps.

 

[MasterRacker]

That works fine as long as I attach it to the KeyDown event instead of KeyPress (KeyPress can't process KeyEventArgs.)



[sub]Jeff
[purple]It's never too early to begin preparing for [/purple]International Talk Like a Pirate Day

I was not born cynical - I earned my cynicism through careful observation of the world around me.[/sub]

 

[earthandfire]

The problem is that KeyPress returns the Key character which is no good for special keys such as the function keys. KeyDown returns the actual key that is currently being pressed.

 

[MasterRacker]

To expand this without cluttering the threadlist, I am doing this in a few multiline textboxes that are set to allow carriage returns. In an effort to get the datestamp appear on it's own line I have tried inserting "\r" and "\n" into the string. In either case the stamp simply goes on the end of the string and shows a box denoting a non-printing character in front of it. Any other quick and dirty solution I could try?

In a related issue, I would also like to position the cursor at the end of the datestamp. The only way I can think of to do this is to scrap my simple solution completely and create a custom textbox control containing overriden PreProcessMessage and Process KeyMessage methods as is shown in this example. Seems like a lot of screwing around to implement a minor feature but maybe that's all there is for it?

[sub]Jeff
[purple]It's never too early to begin preparing for [/purple]International Talk Like a Pirate Day

I was not born cynical - I earned my cynicism through careful observation of the world around me.[/sub]

 

[earthandfire]

try:

TextBoxX.SelectionStart = TextBoxX.Text.Length

Hope this helps.