At 2001-10-22 18:47, Raymond Irving wrote: >Hello Richard, > >Here's a link to a test page that simulates the >problem of form elements & hyperlinks within layers on >NS4 > >http://www24.brinkster.com/dyntools/dyntest/ > >-- >Raymond > >[snip]
(What version of DynAPI are you using? When I test that page locally I get the clicks in v2.54 and the 2001-10-21 snapshot.) This is a rather hard-to-fix bug that manifests itself whenever a browser event (such as a key event) is happening, destined for a browser element (such as the INPUT tag) and not for a DynLayer object. The event catching system in NS4 as it is used in DynAPI is this: The browser generates an event and sends it to the highest catcher for that event. If the document isn't listening for it NS4 next checks a child layer, a grandchild, and so on, until a catcher is found. When DynAPI gets the event it is taken out of the browser event chain. Instead it is passed down _within DynAPI_ to the listeners for it. The effect is that the browser element (the INPUT tag) never sees it. There are a couple of things that can be done to work-around this bug as it is now. One is to not use listeners at all on pages with any FORMs (which is probably unacceptable - why else include the keyboard.js file?). The other is to not include the keyboard.js file on those pages. A third (untested) is probably to catch the keyboard events at the document level and route it to the proper FORM element, but in this case it's browser specific code that shouldn't be in user code. If the bug is to be removed there really is only one way to go (to keep the feature set as it currently is) and that is to rewrite the entire event handling system for NS4 browser events to intercept the event and using the browser's routeEvent() method to make it travel down to the next catcher. Hope I cleared it up more than I obfuscated it... /Lunna _______________________________________________ Dynapi-Dev mailing list [EMAIL PROTECTED] http://www.mail-archive.com/dynapi-dev@lists.sourceforge.net/
