Tim/All,

Just been doing some digging to try and find out why the keyboard events don't work in non-edit mode.

I notice you said that they do not work when you attach events. However it looks like they don't work full stop, events attached or not. It seems that the key event never gets to the html document. If I include some java script for mouse events they work fine but have no effect for key presses. Although it is strange that they effect the scroll bars.

I'm still a little rusty on what most of the com interop stuff does but can you think of anything which would limit/exclude key presses?

Ste

Off the top of my head, no, I don't know.

Observations:

UpdateUI gets called on keypresses, when the control has the focus. You can verify this by clicking on the control with the mouse, then pressing keys. If you have a Debug.Writeline in UpdateUI, you can see the method gets called.

TranslateAccelerator never seems to get called, yet I reckon it should be.

PreProcessMessage always gets called. This is an override of one of Control's methods. The message argument tells you which key was pressed. This is a good bet if you just want to trap certain keypresses.

You can also attach event handlers to specific HTML elements ... but this is where things get strange. For example, I can load a document which includes an input element of type Button, and then attach an event handler to the button by getting its HTMLInputTextElementEvents2_Event interface. However, when I do this, the button no longer appears to depress when clicked (although the event does fire). This type of behaviour makes it really hard to create a DHTML interface for an app. I believe similar problems crop up if you try to do this with the WebBrowser control. I've raised this a couple of times with Microsoft but not gotten an answer as yet (still hopeful!). However, it is currently the same in Everett beta.

Tim

I too have had the same problems attaching events, although you can do it rather effectively using some sample code posted by Chris Paldino. I've also been experimenting with the GetExternal call and this seems to work well. All in all this makes creating a DHTML interface for an app possible.

The following code works both in the HtmlEditor and WebBrowser control, although I still can't get the key presses to work for the HtmlEditor.

Shall I add the following code to the HtmlEditor control with some plumbing to handle the event?

//Attach the events
m_htmldoc.onkeydown = this;
m_htmldoc.onclick = this;


[DispId(0)]
public void DefaultMethod()
{
// Get the event.

mshtml.IHTMLEventObj pobjEvent = ((mshtml.IHTMLDocument2)
axWebBrowser1.Document).parentWindow.@event;

// Display information about the event.

Console.WriteLine("Event Info\nType: " + pobjEvent.type + "\nElement: " +
pobjEvent.srcElement );

// That's all folks.
return;
}

Whoops, that should have been Nicholas Paldino.

Ste

Steven,

I've had a look at this, and as you say, the onClick seems to work fine. Please do add this to the control and send your modifed code; I'd like to test it further.

Tim

Sure, will do.

Ste

I've added Steven's code (just a little amended) to the latest download.

Tim

Cheers Tim.

I notice that most of the key presses work, as commented in the code, great! Unfortunately the up and down keys do not, which is what led me to the conclusion that none of the keys worked. If you try the up and down arrows you'll see that they don't get passed as events, instead they seem to be controlling the scroll bars which is not normal behaviour(I think) if the html doc has focus. Still a problem, I'll get back to you if I find a solution.

Thanks,

Steven

Some brief experimentation suggests that IE will scroll if you press the arrow keys, unless the caret is in a user input control.

Tim