First key press lost when Windows Shell is replaced with Windows Forms application

I have succesfully replaced the Windows Shell following the approach given in this SO question.

However, I have detected that the first key press is lost and is a bit of an annoyance for the user. The solution we have tried is to activate开发者_运维问答 the form in the OnShown event:

private void OnShownLoginForm(object z_sender, EventArgs z_e)
{
    Activate();
    m_loginTextBox.Focus();
}

But this hasn't solved the problem. Do you have any clue of what is happening?

You could try using the System.Windows.Forms.SendKeys Class (MSDN Documentation) to send a key press event to the form when in the Form Load event. If that doesn't help, try sending the keyboard events in the Form.Shown event since Form.Shown is the last event in the form start-up process.

Sounds like something caused by maybe another control getting focus first. Does the textbox have a taborder, and can you set it to 0? Focus should then be on it after the form loads.

Otherwise try creating a new form to test with, it really doesn't seem reproducible.

I do not know if it is related but I had a similar problem where the tabindex property of a webform did not work by pressing the TAB key, after focusing on the first input at page load, until the user first clicked on the form with the mouse.

I did not have access to the source code so I tried solving it with javascript.
Until the first mouse click, all keyboard strokes, including the TAB key, activated the keypress event, TAB key was undetected by keydown/keyup on page load.

I learned that the TAB key activated the keypress event and I could access the keycode through it. simply registering the keypress event and manually switching to the next input with jQuery worked. after the first mouse click the form behaved as expected, TAB key was no longer caught by keypress event.

here is a code sample:

function tabNext(e){
    if(e.keyCode == 9){
        // do work
    }
}

$('input').keypress(tabNext);