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

[Raymond I. <xw...@ya...>]

Sound pretty cool Andrew. 

The documenations always lag behind the source. That's
just how things sometimes goes.

Keep up the good work
__
Raymond Irving 

--- Andrew Gillett <an...@zo...> 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).
> 
> 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.
> 
> 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).
> 
> I have tested my change on FireFox and IE and I'm
> confident that it 
> won't introduce any problems.
> 
> 
> Andrew
> 
> 
---------------------------------
DynLayer Key Event
handlingdynapi.library.setPath('../src/');dynapi.library.include('dynapi.api');dynapi.library.include('DynKeyEvent');function
init(){	var lyr = new DynLayer('Text:  [input] ');
dynapi.document.addChild(lyr);	lyr.addEventListener({	
onkeydown:function(e){alert('dynlayer');}	});
dynapi.document.addEventListener({	
onkeydown:function(e){alert('document');}
});}dynapi.onLoad(init);
---------------------------------
Template Key Event
handlingdynapi.library.setPath('../src/');dynapi.library.include('dynapi.api');dynapi.library.include('TemplateManager');dynapi.library.include('DynKeyEvent');function
init(){	var tpl = new Template('Text:  [input] ');
dynapi.document.addChild(tpl);	tpl.addEventListener({	
onkeydown:function(e){alert('template');}	});
dynapi.document.addEventListener({	
onkeydown:function(e){alert('document');}
});}dynapi.onLoad(init);