>>>Fred's where I started from, but since I need to do syntax coloring, not interaction with selection, those buttons are of no use in this context. I did use it before in a pet project, though.
>>>
>>>Tx, I'll take a look at Peter's stuff.
>>
>>The issue you mention is exactly one of the issues I found troublesome in Yousfi's code. Read the comments I wrote in my WBEventHandler.prg. Esp. the way Yousfi uses GetAsyncKeyState is troublesome. Instead of looping thru all 255 places, you should only test the places in the buffer that you are interested in. The code also handles ctrl, alt, shift, etc.
>
>Well thanks to Microsoft, we get no parameters in this eventhandler, so this way of poking at the buffer (and there seems to be no way to get that buffer either, eh?) seems to be the only way...
>
>I'm thinking of writing a simple js onkeyup or onkeydown handler, which would store the event parameter somewhere in the DOM and then the fox eventhandler may somehow pull it out. Not holding my breath that it may work, though.
>
>update: now I found the link in your prg, and in the C# example there it says
>private void HtmlElement1_KeyDown(Object sender, HtmlElementEventArgs e)
>
>So, ahem, the see sharp guys get the parameters and e is fully exposed, they can get its full PEM set. It's easy then. Our eventhandler is blind.

It's been a while since I've done this but the way you can do this in IE is:

FUNCTION GetEventObject()

IF ISNULL(THIS.oDoc)
   RETURN .NULL.
ENDIF

RETURN this.oDoc.ParentWindow.Event
ENDFUNC

Roundabout way of getting access to the event object although I'm not 100% sure this still works if you're running in IE 11 mode which uses the standard DOM event system. I pulled this code out of Help Builder 4 years ago and never looked back at that support train wreck :-)

+++ Rick ---