The kind of stuff that's not needed on a regular basis...but sometimes comes up...

• The KeyData property is the raw data of the Key Up/Down event, expressed in the form of a [Flags] enabled System.Windows.Forms.Keys enum.
• The KeyCode property is the KeyData, stripped of any Modifiers:

public Keys KeyCode { get{return this.keyData & Keys.KeyCode;}}

• The Modifiers is the KeyData, stripped of its KeyCode:

public Keys Modifiers{
    get{return (this.keyData & ~Keys.KeyCode);}
}

The above can be expressed as below:

Ouput:
---
KeyData:ControlKey, Shift, Control
KeyCode:ControlKey
Modifiers:Shift, Control
---
KeyData:K, Shift, Control
KeyCode:K
Modifiers:Shift, Control

The rest is the KeyEventArgs are just trivial properties.

Small stuff
Note the difference between ControlKey and Control -- ControlKey is when it is just the Control key being pressed, and is not modifying another key. If you press another key (eg: K) the Control key is now no longer just a key in itself, but the modifier of the key...hence its change to being called Control, and not ControlKey.

Links:

• KeyEventArgs Class
• System.Windows.Forms.Keys enum

Somewhat of a continuation of the discussion brought up in the last post, I've been looking into using Screen captures as part of an error reporting WebService, and trying to find a way that doesn't rely on API and therefore in higher CAS privileges than might sometimes be available.

So far...I haven't found a solution (I tried SendKeys, but got fun system wide hangs).

The only (working) solution I see is using API calls to GetActiveWindow, etc.

Does anybody have a man Read More »

In PInvoke.NET you'll find an instructive note saying:

"You can avoid using FindWindow which is a native code by calling a combination of Process.GetProcessesByName and Process.MainWindowHandle."

The example given is somewhat like (using System.Diagnostics):

Process[] processes = Process.GetProcessesByName("notepad");

foreach (Process p in processes) {
  IntPtr pFoundWindow = p.MainWindowHandle;
  ...
}

The point is:

Avoid API calls wherever possible -- especially these days: whereas this was not so much an issue in ASP.NET and Winform apps (we could always fiddle CAS for more rights), I think that with API calls being unportable/impossible in Silverlight, this is going to quickly become an issue.

Coders (such as me...) who relied on API's to get around shortcomings of NET 1.1 and NET 2.0 will be looking at the problems a second time, trying to figure out ways to do in NET only, hoping that some safe wrappers were added in NET 3.0/3.5...