Re: [Dynapi-Dev] A problem with key event handling

[Kevin <ke...@ke...>]

Andrew Gillett wrote:

> Hi,
> 
> I've been having some problems with keyboard events in DynAPI. So for 
> the last few weeks I've been trying to understand the DynAPI event 
> model, particularly how it relates to keyboard events. After an awful 
> lot of effort, I've come to understand how the browser event model works 
> (fairly straightforward) and how DynAPI events work (anything but 
> straightforward).

Yes, I worked through it a while back. The complexity evolved to attempt
to cover all key event models NS4 (capture only) IE (bubble only) MOZ 
(both) though I think it only uses one. Unfortunately the only way of
writing a decent NS4 portable application was to handle everything at
the DynDocument level.

> As far as I know, the DynAPI 3 event handling model isn't documented at 
> all, so I'm in the process of writing up an explanation of  how it 
> works. I'll post a url to it soon.

Look forward to it.

> Anyway the problem I've experienced is illustrated by the two attached 
> files. The first example, DynLayerEvent.html, works as you would expect. 
> The document contains a DynLayer which contains an <input> element. 
> There are "keydown" event handlers attached to both the DynLayer and the 
> document. When the input has focus and you press a key, both handlers 
> are invoked.
> 
> Now look at TemplateEvent.html. It is almost exactly the same except 
> that instead of DynLayer, I've used a Template. "Template" is a fairly 
> simple subclass of DynLayer. In this case, when you press a key in the 
> input field, only the document event handler is triggered.
> 
> The cause of this problem is at line 151 of api/ext/dynkeyevent.js :
> 
> DynElement.prototype.captureKeyEvents=function() {
>     var elm=(this.getClassName()=='DynLayer')?this.elm:this.doc;
>     if(!elm||!this._hasKeyEvents) return true;
> 
> This code fails for any subclass of DynLayer. The correct behavior for a 
> subclass of DynLayer is to assign this.elm to the local variable elm. 
> Instead, elm is assigned this.doc, which is null for any class other 
> than DynDocument. This bug makes it impossible to write a widget that 
> extends DynLayer and is still able to handle key events using a DynAPI 
> event handler.
> 
> A fixed version of the function looks like:
> 
> DynElement.prototype.captureKeyEvents=function() {
>     var elm=(this.getClassName()=='DynDocument')?this.doc:this.elm;
>     if(!elm||!this._hasKeyEvents) return true;
> 
> The same code also needs fixing in the releaseKeyEvents function 
> (dynkeyevent.js, line 167).

Good fix for that subclassing bug though I don't have cvs access to do
any updates.

Kevin.


> I have tested my change on FireFox and IE and I'm confident that it 
> won't introduce any problems.
> 
> 
> Andrew
> 
>