I was
not aware of the load event capturing on a DynLayer. If it's only used by
LoadPanel, then I don't see any problem moving it into the LoadPanel
code.
I'm not sure what you mean? LoadPanel invokes a load event. Whether it
is captured or not is up to the developer.
this is NOT the case.DynLayer.js:
55 this.elm.captureEvents(Event.LOAD);
56 this.elm. {};LoadPanel.js
146 lyr.
147 lpanel.loadElement.As show above, the onload event is being sed by the loadpanel. this is the only widget that uses it. As such, I would suggest moving it from the dynlayer.js to loadpanel.js
> - mouse events are released by this widget when it loads a file. WHY?this is only done for netscape 4, the code has been in there for ages,
but the reason seems to be to stop users from clicking on anything while
something is loading, because clicking on something (like a link) kills
the load. i've tried taking that out, but things work better with it
left in.
in that case, why don't we stop the actual events instead of stopping the capture of them. It should be possible to force them all to return false instead of actually not handling them.
Well
we could, but why bother? Is there any advantage in doing
this? The disadvangtage would be that if we ignored (return false,
whatever) events rather than not capturing them then we would only be able to
block events that were handled by the api, and not non-api events
like clicking on an href.
I've
done a bit of LoadPanel work in the past, but unfortunately I haven't got much
time at the moment to do any updates, so if you want to change some of this
stuff you should have a go yourself, submit a patch, or update
cvs.
Cheers,
Cameron.
