Menu
▾
▴
dynapi-dev
|
From: Andrew G. <an...@zo...> - 2004-09-16 23:34:28
Attachments:
DynLayerEvent.html
TemplateEvent.html
|
<html>
<head>
<title>DynLayer Key Event handling</title>
<script language="JavaScript" src="../src/dynapi.js"></script>
<script language="Javascript">
dynapi.library.setPath('../src/');
dynapi.library.include('dynapi.api');
dynapi.library.include('DynKeyEvent');
function init()
{
var lyr = new DynLayer('Text: <input type="text"/>');
dynapi.document.addChild(lyr);
lyr.addEventListener({
onkeydown:function(e){alert('dynlayer');}
});
dynapi.document.addEventListener({
onkeydown:function(e){alert('document');}
});
}
</script>
<script language="JavaScript">dynapi.onLoad(init);</script>
</head>
<body>
</body>
</html>
|
|
From: Raymond I. <xw...@ya...> - 2004-09-17 21:16:58
|
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);
|
|
From: Kevin <ke...@ke...> - 2004-09-17 21:19:09
|
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
>
>
|
|
From: Andrew G. <an...@zo...> - 2004-09-19 00:32:30
|
Kevin wrote: > 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. Oh. I hadn't given a thought to NS4. Obviously I don't really understand the event handling as well as I had thought. I'd better find a copy of NS4 and play with it before I publish any explanations :) Can you tell me if NS4.0 and NS4.7 both use the same key event models? Andrew |
|
From: Kevin <ke...@ke...> - 2004-09-19 15:48:16
|
Andrew Gillett wrote: > Kevin wrote: > >> 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. > > > Oh. I hadn't given a thought to NS4. Obviously I don't really > understand the event handling as well as I had thought. I'd better find > a copy of NS4 and play with it before I publish any explanations :) > > Can you tell me if NS4.0 and NS4.7 both use the same key event models? I believe so. NS4 is only 2% of the market and I can't test it without building another Linux 7.2 system which has NS4 :( Peter's http://www.quirksmode.org/ page is great for explaining events: under Javascript -> Events Kevin > > 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 > Dyn...@li... > http://www.mail-archive.com/dyn...@li.../ > |
|
From: Leif W <war...@us...> - 2004-09-19 16:22:09
|
> ----- Original Message ----- > From: "Kevin" <ke...@ke...> > To: <dyn...@li...> > Sent: Sunday, September 19, 2004 11:51 > Subject: Re: [Dynapi-Dev] A problem with key event handling > > Andrew Gillett wrote: > > Kevin wrote: > > > > > 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. > > > > Oh. I hadn't given a thought to NS4. Obviously I don't really > > understand the event handling as well as I had thought. I'd better find > > a copy of NS4 and play with it before I publish any explanations :) > > > > Can you tell me if NS4.0 and NS4.7 both use the same key event models? > > I believe so. NS4 is only 2% of the market and I can't test it > without building another Linux 7.2 system which has NS4 :( > > Peter's http://www.quirksmode.org/ page is great > for explaining events: under Javascript -> Events Try this, replace number 32 with anything from 1-32. ftp://ftp32.netscape.com/pub/communicator/ Browsers are under the language directories ("english"). You can get as old as 4.08 (win32, non-linux, mac) and as new as the 4.79 (win32, linux 2.2, mac) and 4.8 (win32, linux 2.2, mac) browser. Leif |
|
From: Andrew G. <an...@zo...> - 2004-09-20 23:01:49
|
Kevin wrote: >I believe so. NS4 is only 2% of the market and I can't test it >without building another Linux 7.2 system which has NS4 :( > >Peter's http://www.quirksmode.org/ page is great >for explaining events: under Javascript -> Events > > Thanks for this link. A very helpful explanation of NS4 event handling. Leif W wrote: >Try this, replace number 32 with anything from 1-32. > >ftp://ftp32.netscape.com/pub/communicator/ > >Browsers are under the language directories ("english"). You can get as >old as 4.08 (win32, non-linux, mac) and as new as the 4.79 (win32, linux >2.2, mac) and 4.8 (win32, linux 2.2, mac) browser. > >Leif > > I went to browsers.evolt.org - it goes back as far as Navigator 0.4 (yes 0.4, 16 bit). Remember 16 bit programs and Windows 3.1? It can be quite amusing to get an old pre-javascript web browser and see how it renders the most ordinary of modern web sites. Anyway, I downloaded the windows versions of NS4.04 and NS4.79. NS4.04 doesn't run _any_ of the dynapi examples. It complains about the many places throughout dynapi where a "function does not always return a value.". When I get some time I'll make a list of them, if anyone is interested. NS4.79 seems to work quite well. By the time I finish with this I'll hopefully have some useful documentation on dynapi event handling. I'll keep you posted. Andrew. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X