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
------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Dynapi-Dev mailing list [EMAIL PROTECTED] http://www.mail-archive.com/[EMAIL PROTECTED]/
