Well I've been looking at the event files looking for that bug. The
issue here is that we have two types of events: the ones that must
bubble and the ones that not. It does make a sense that mouseovers
bubble while it doesn't ( at least it is not that clear ) that 'creates'
and 'precreates' do.
If you look at the listeners.js file you will see that DynEvents by
default have bubble set to false, so events such as 'create' and
'precreate' or any custom ones don't bubble.
Then when you include 'mouse.js', you get the DYnMOuseEvent that extends
the DynEvent and does bubble by default. This is how I managed this
issue when I rewrote the event code in v2.5. I still believe this is the
way it should work.
Now I think that the bug you are referring to happens only with simple
events. The simpleevent code is as follows.
DynObject.prototype.invokeEvent = function(type,e,args) {
var ret = true;
if(this["on"+type]) ret = this["on"+type](e,args)
if(ret && this._oldInvokeEvent(type,e,args) && this.parent)
this.parent.invokeEvent(type,e,args);
}
As you see there are no different objects here, just a single method. So
far there is no way to know wheter the invoked event must bubble or not.
I am still thinking of the best way of fixing this. All this event stuff
is pretty complex after all and I wouldn't want to add yet another extra
parameter. As a general rule if your code becomes too complicated then
you're looking at the problem from the wrong side. 99.9% of programs can
be completed with simple code.
Another idea I'm playing with is having one single event handler
attached to the document instead of multiple handlers atacched to every
layer. I don't know if it can be done: we'll see. Just downloaded your
demo page with all the scripts and I'm seeing how big those changes are.
This time I'm making my mind on writing some extensive documentation on
how it works and why does it work that way. I've been looking at the
sourceforge logs and we've got several thousand downloads. Enought
people to make it worth the boredom.
Back to the trench now,
Dan Steinman wrote:
> Yes this is the correct solution, I noticed this a little while ago and had no
>problems since.
>
> There is also another major bug that should be fixed up in 2.5x. The precreate
>event gets called multiple time (an extra time for each time it's nested). The
>DynObject.flagPrecreate() method is set up incorrectly. The fix I did in my working
>copy isn't compatable with v2.5, so someone else will have to do a quick fix.
>
> Regards,
> Dan Steinman
>
>
> On Mon, Nov 05, 2001 at 01:20:18AM +0100, Richard Bennett wrote:
>
>>Hi,
>>This seems to me to be a good solution.
>>I applied the changes, and updated the test-file to reflect this.
>>I did comment the changes, so they can easily be reversed if shown they have
>>any negative effects, or a better solution is suggested.
>>At least now we can start using complex widgets again.
>>Great !
>>
>>
>>----- Original Message -----
>>From: "Joachim Lundgren" <[EMAIL PROTECTED]>
>>To: <[EMAIL PROTECTED]>
>>Sent: Saturday, November 03, 2001 4:28 PM
>>Subject: Re: [Dynapi-Dev] Re: [Dynapi-Chat] Serious Event model bug
>>
>>
>>
>>>I sent a fix for this ages ago (August, that is) to this list. That was
>>>
>>the mistake I did, it should have been to the bug/patches area. I simply
>>forgot it afterwards. And now I'm doing it again...
>>
>>>(The kludge outlined below is NOT the same as the August kludge.)
>>>
>>>The problem is the objects share the same eventListener array [in the
>>>
>>example it can be verified with an
>>alert(scrollpane1.eventListeners===scrollpane2.eventListeners); line].
>>
>>>(Because EventListeners are a rather fundamental aspect of the code it is
>>>
>>less of a kludge than it really is :-)
>>
>>>In dynapi.js, make the DynObject function end with:
>>>
>>> // These aren't used unless listeners.js is included
>>> this.eventListeners = [];
>>> this.hasEventListeners = false;
>>>};
>>>
>>>and comment out or remove the first line in listeners.js:
>>>DynObject.prototype.addEventListener=function(listener) {
>>> // if(!this.eventListeners) { this.eventListeners = []; } // <-
>>>
>>remove this line (commented here)
>>
>>> this.hasEventListeners = true;
>>> for (var i=0;i<this.eventListeners.length;i++) if
>>>
>>(this.eventListeners[i]==listener) return;
>>
>>> this.eventListeners[this.eventListeners.length]=listener;
>>>}
>>>
>>>NB: This fixes the example and my own quick-and-dirty test-case, and I got
>>>
>>the desired results with these changes. Please check so it doesn't break
>>anything else! The August fix worked for the original bug submitter, and I
>>don't think the difference between my original fix and this version breaks
>>anything.
>>
>>>/Lunna
>>>
>>>
>>>At 2001-11-02 03:01, you wrote:
>>>
>>>>Hi,
>>>>I added a testfile to the /tests directory in CVS or latest snapshot.
>>>>See:
>>>><wrap>
>>>>
>>>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/dynapi/dynapi/tes
>>>
>>t
>>
>>>>s/secondary_inheritance.html?rev=1.1&content-type=text/html
>>>>
>>>></wrap>
>>>>Should make debugging this problem easier.
>>>>I would hope it is possible to debug this issue at it's core, instead of
>>>>changing the architecture of all the widgets.
>>>>
>>>>Cheers,
>>>>Richard.
>>>>
>>>>
>>>>----- Original Message -----
>>>>From: "Laszlo Teglas" <[EMAIL PROTECTED]>
>>>>To: <[EMAIL PROTECTED]>
>>>>Sent: Wednesday, October 31, 2001 4:42 PM
>>>>Subject: [Dynapi-Chat] Serious Event model bug
>>>>
>>>>
>>>>
>>>>>After spending the better part of a day trying to track down a bug I
>>>>>
>>>>though
>>>>
>>>>>I introduced into my code, when migrating from a November 2000 version
>>>>>DynAPI script to the current 2.55a version, I realized that something
>>>>>
>>more
>>
>>>>>serious was causing my agony.
>>>>>
>>>>>After searching through the lists and bug reports, I came across what I
>>>>>think is the earliest mention of this problem. Bug number 425789
>>>>>
>>reported
>>
>>>>on
>>>>
>>>>>May 20, 2001.
>>>>>
>>>>>Basically any widget that does not inherit directly from DynLayer can
>>>>>
>>not
>>
>>>>be
>>>>
>>>>>used more than once on a single page, unless you only want one
>>>>>
>>>>EventListener
>>>>
>>>>>for the whole lot (very unlikely).
>>>>>
>>>>>If you try to create multiple EventListeners (i.e. one for each widget
>>>>>
>>of
>>
>>>>a
>>>>
>>>>>class not derived directly from DynLayers), only the last EventListener
>>>>>assigned to one of this second generation widgets will fire. And it
>>>>>
>>will
>>
>>>>>fire on all widgets that are instances of the same class.
>>>>>
>>>>>I have been mainly working with the ButtonImage class derived from
>>>>>
>>>>DynImage,
>>>>
>>>>>but I believe this will affect List, PushPanel and any other second
>>>>>generation widget.
>>>>>
>>>>>Seeing that this problem has been around for some time, I imagine the
>>>>>solution will require a lot of work. A temporary solution would be to
>>>>>rewrite any second generation widget to inherit directly from DynLayer
>>>>>
>>and
>>
>>>>>including any other inherited functions from it's former parent. I
>>>>>
>>realize
>>
>>>>>this is redundant and counter to OOP, but at least we would have
>>>>>
>>complex
>>
>>>>>widgets that work. There is no point in streamlining the core for
>>>>>performance if the core is broken. This would be a relatively simple
>>>>>
>>fix.
>>
>>>>>And could be reversed easily once the event model is fixed. This would
>>>>>
>>>>also
>>>>
>>>>>not require changes in code implementing these widgets, thus have
>>>>>
>>little
>>
>>>>>effect on users other than performance due to redundancy.
>>>>>
>>>>>The other solution is to fix the problem in the event model. This will
>>>>>
>>>>take
>>>>
>>>>>longer, but should be top priority. The whole purpose of DynAPI is to
>>>>>
>>have
>>
>>>>>complex widgets, and a common API. For simple widgets anyone can create
>>>>>simple JavaScript that has less overhead than DynAPI. Therefore this
>>>>>
>>bug
>>
>>>>>undermines the purpose of DynAPI.
>>>>>
>>>>>We did not have this bug in 2.0. What has changed so drastically since
>>>>>
>>2.0
>>
>>>>>in the event model or in other parts of the core that introduced this
>>>>>
>>bug.
>>
>>>>>Any idea?
>>>>>
>>>>>
>>>>>Laszlo
>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>Dynapi-Chat mailing list
>>>>>[EMAIL PROTECTED]
>>>>>https://lists.sourceforge.net/lists/listinfo/dynapi-chat
>>>>>
>>>>>
>>>>
>>>>_______________________________________________
>>>>Dynapi-Dev mailing list
>>>>[EMAIL PROTECTED]
>>>>http://www.mail-archive.com/dynapi-dev@lists.sourceforge.net/
>>>>
>>>
>>>
>>>_______________________________________________
>>>Dynapi-Dev mailing list
>>>[EMAIL PROTECTED]
>>>http://www.mail-archive.com/dynapi-dev@lists.sourceforge.net/
>>>
>>>
>>
>>_______________________________________________
>>Dynapi-Dev mailing list
>>[EMAIL PROTECTED]
>>http://www.mail-archive.com/dynapi-dev@lists.sourceforge.net/
>>
>
> _______________________________________________
> Dynapi-Dev mailing list
> [EMAIL PROTECTED]
> http://www.mail-archive.com/dynapi-dev@lists.sourceforge.net/
>
>
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://www.mail-archive.com/dynapi-dev@lists.sourceforge.net/
