Capturing KeyPress "Always" !!

Capturing KeyPress "Always" !!

• christinamarygeprge

  Forms cannot have the input focus themselves. Even if you have set KeyPreview to true, there must be a control on your form that contains the focus in order for key events to be sent to that control and intercepted by your form.
  
  

• Peter Tübben

  Hi,

  since it's a good idea anyways to have one control on your form that gets the focus right away (so your user can start working with the tab-key and so on without having to click on the from prior to that) that's what you can to:
  After the
  InitializeComponent()
  in your constructor, give the focus to one of your controls:
  this.YOUR_CONTROL.Focused = true;

  Finch82.

  
  

• flodis79

  If it *is* a bug with the WebBrowser control, then I bet you have the form laid out so that the WebBrowser control is first in the Tab order. I bet if one of your TextBoxes had control first, you wouldn't have that problem. Just a SWAG.

  Also, if you have trouble after the WebBrowser has finished downloading a page, maybe you can set the Focus of one of your TextBoxes manually

  
  
  

• Ram Pamulapati

  StanScott wrote:

  The best way I've found to do this is to use a bit of Javascript code.  At the end of my page I put this: <script language="javascript">     document.getElementById("yourControl").focus(); </script> Cheers,

  I really think this has nothing to to with web services, since the web service could not capture a key press when window is not active. He also writes "when the application starts".

  It would probably be a good idea to read the whole text before replying.

  
  

• koiravahti

  Thanks Harold Jimenez but of course i already tried that...

  Maybe i discovered a bug in relation to the fact that my form uses a WebBrowser control !

  Before writting the first post of this thread, i had the chance to try exactly what you're proposing in your post above...

  The form will get the KeyPress events only if before i touch the keyboard, i click the VScroll bar in the WebBrowser display area or if i click on one of my TextBox controls.

  And i noticed that even then, i will easily get back to a state where none of the From'S controls have the focus (e.g. After the WebBrowser as finished downloading a page !)

  I did go around the problem by abandoning all of the features in my application that where suppose to work with KeyPress events.

  Everything is now done with the mouse !

  I like .NET but i also miss the time when i was developing on "XT Intrinsic" and OSF/MOTIF. Having full control on everything was a lot easier back then !

  So Long UNIX, ... Heil Microsoft !!

  Aco.

  
  
  

• PaloMisik

  Hmmmm ... this seems strange. My form seems to capture the key events right from the beginning.
  
  

• Richard Hough

  This looks like a good issue for the MSDN Product Feedback Center. If you believe this behavior to be a bug, or at the very least something to be fixed, this is the place to report it: http://lab.msdn.microsoft.com/productfeedback/ You'll be able to track your bug over easily over time and talk directly with the team responsible.

  Scott Nonnenberg

  
  
  

• K42

  Thanks Finch82 for the suggestion.

  Unfortunetly, "Focused" is a read only property... Using "Focus()" will not help either.

  Even if it would have worked for when the application starts, there is lot of intances where the focus will be lost by all controls in a form... This easilly becomes an unmanageable situation...

  There has to be something more obvious.... I can't be the only one in such a situation.

  Thanks for any help !

  Acoquinar

  
  
  

• hemant Kanchan

  .
  
  

• Francois-Regis Colin

  This issue has sense if you think from the perspective of "Contexts".

  The AxWebBrowser is simply the IExplorer container/Server ActiveX Control embedded into your app. This unmanaged COM object has just some registered events available for notification (visible from its IDL metadata descriptor) and  it just notifies this events to the parent as any other ActiveX control that notifies its parent (some common mechanisms are interfaces, connection points etc). Once you request a web page, some elements inside your web page (like combo boxes, input boxes, radio buttons and even anchors(aka links)) acquire the focus and those elements behave worse (if you are trying to capture some activity), because they do not send messages to container of the AxWB, they behave like normal HTML controls (quite different from Form Controls) those events are trapped by the scripting context and processed through VBScript, JScript, JavaScript directly in the HTML page. Also if this were possible, this could be a security hole used by malicious programmers.

  Also there is something called "Message Pump" that every form (window) has inside, and every message received is pushed into it and processed by the main thread. If you perform any action no matter if this is done in a child control, it is posted to the message pump so this queue is used by the window to preview keyboard events.

  It seems some AxWB messages (like WM_KEYUP, WM_KEYDOWN) don't go to the window's message pump and are processed directly inside.

  There are some advanced mechanisms (like hooks) to capture everything (I mean it, everthing!), but it goes beyond the scope of this explanation

  I hope this helps to understand (at least)!

  
  
  

• SteveHagget

  How about a "fake" click.....to give something the focus

  private void Form1_Shown(object sender, EventArgs e)

  {

  Form1_Click(sender, e);

  }

  private void Form1_Click(object sender, EventArgs e)

  {

  Console.WriteLine("CLICKED");

  }

  
  
  

• Alois Kraus

  Having the same issue with VB.NET:
  Platform: VS 2003 running on XP Pro
  Web Control: AxWebBrowser1 (imported into tool box)
  1. Created single form

  • Set KeyPreview to 'True'
  • Added key trapping to the 'KeyDown' event
  • In Form1_Load event added following line of code:

  • AxWebBrowser1.Navigate2("www.yahoo.com")

  2. Added one TextBox (made sure it was a TabIndex 0 )
  3. Added AxWebBrowser1 (made sure it was a TabIndex 1 )
  4. Ran the app and anytime the TextBox had the focus, the KeyDown event would work properly, but as soon as the focus was changed to the web control, KeyDown would stop working.

  Interesting to note that if no navigation is performed in the web control (no 'Navigate2'), KeyDown works just fine when the focus is on the web control - it seems to be an issue only after the web control has been told to go to a URL.

  We use the same web control in VB6 where the KeyDown event works just fine no matter what control on the form has the focus.

  My comrades seem to think that this is a security 'fix' implementation - I think it is just a pain in the butt.

  
  

  
  

• Daksh Khatter

  The best way I've found to do this is to use a bit of Javascript code.  At the end of my page I put this:
  
  <script language="javascript">
      document.getElementById("yourControl").focus();
  </script>
  
  Cheers,
  
  
  

• Ramana G.V

  That is not accurate at all!
  Forms do receive focus no matter if they don't have child controls!
  
  Just do the following:

  1. Create a windows application project (language of your choice C#, VB.NET etc)

  2. Activate KeyPreview (set it to true)

  3. Create an event handler for KeyUp (you can also use KeyDown and KeyPress) with MessageBox.Show("Key released!!"); as body.

  4. Run your program.

  5. When the form appears press any key

  It works event with special keys like 'Caps Lock', 'Num Lock', 'Print screen', 'Functions', 'Shift', 'Control' etc.

  
  
  
• Capturing KeyPress "Always" !!