>>>>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.
>
>I'm not sure what you suggest. Is it that the event
>

PROCEDURE HTMLElementEvents_onkeydown() AS VOID

>does have a parameter?
>
>If so, what is it then? The key? Or the multiple keys? Isn't the GetAsyncKeyState() function just as powerful?

I've bolded the C# example I found on the page for which you left a link in your code. So they get the parameters (the object triggering the event, and the event arguments object) and can parse them at will.

>BTW, does my code work in your environment?

I was only reading it today. Patience.