Menu
▾
▴
dynapi-dev
|
From: Jordi 'I. M. <jmi...@or...> - 2001-01-11 12:14:35
|
I'm missing events... did I screw something ? First I thought but then going back to the latest code (
before my modifications ) I am missing those same events. Ohh please just a little luck from time to
time !!!!!
In NS you can apply the same "for (each image in doc) img.lyrobj = myself" event trick to the links
array.
Jordi 'IlMaestro' Ministral wrote:
> I have updated CVS with a new events.js that should fix IEs event problems. All the example files
> worked fine. This is what happened ( at least this is something I found, maybe there are still
> other issues ):
>
> - All browser events in DynAPI are captured and passed to the same EventMethod. This eventMethod
> identifyes the physical layer, cancels browser event, searches for the appropiate DynmLayer object
> and invokes its event.
>
> - In IE, in order to access the DynLayer object we use the lyrobj property of the DIV itself. This
> property is set when creating a layer so from code executed within the DIV's scope we can still get
> to our DynLayer obj. The problem with our contents was that when clicking on a text, most of the
> times the srcElement of the event was not the DIV but a FONT, TD, TR, TABLE, UL,... element. That
> element did not have a pointer to the dynlayer and thus the API could not route the event properly.
>
> - This issue was partially solved for images by doing:
>
> if (is.ie) for (i in dlyr.elm.all.tags("img")) dlyr.elm.all.tags("img")[i].lyrobj=dlyr;
>
> So images had a pointer to the layer aswell. This we would have needed to do to all elements in our
> content, somethig really painful. Instead, I added this line inside eventmethod.
>
> for(;is.ie && !realsrc.lyrobj && realsrc.parentElement &&
> realsrc.parentElement!=realsrc;realsrc=realsrc.parentElement);
>
> Which actually makes realsrc travel IE's object hierarchy until we find the lyrobj reference. By
> doing so I fixed events in IE5 and 5.5. I'm not that sure everything is fine now, but it is an
> improvement.
>
> There are several lines in that method such as that
>
> if (e.type=="mouseover" || e.type=="mouseout") return false;
>
> just before the bubbleEvent() call that I don't understand but I prefer not to touch them.
>
> By the way, it seems that when clicking on a selectable text, NS does not fire a click event.
> Mousedown and mouseup are fired, but click isn't. We could fire it manually but then when clicking
> outside a text we would get two onclicks.
>
> Tell me if I broke something. Sure I did.
>
> Cya
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
|
|
From: Richard :o <ma...@ri...> - 2001-01-11 14:12:37
|
Ok, i tried the latest snapshot with your two altered files from the cvs, it's basically ok, but: * Buttons are ok now regarding text/events, but if you double-click a text-button it selects bits of the caption, so it needs a cover layer after all. * The list widget still doesn't mouse-over * Mouse-over doesn't seem to occur for a layer with image. I'm afraid it seems this whole precreation thing has somewhat passed me by, probably it happened when I was offline over Christmas, so I'll check the archives for relevant info. What I don't understand though is why Pascal keeps saying that his widgets will be obsolete under the new DynAPI, while they all work perfectly alright under the latest snapshot, with latest events + dynlayer files. Is it a question of not working ok under DOM maybe? The only widget I could not get working without altering was you're scrollbar, which gives out of stack error in scrollbar.js, line 137 which is a setSize(w,null) call. * Now browser.js has to be included in your page before dynlayer.js or error "is undefined dynlayer.js line 265", this was not the case a while ago. I guess that's due to the precreation changes. Keep up the war, Richard :o ma...@ri... www.richardinfo.com (Everything running on, and ported to the 19/12/2000 snapshot of DynAPI2) ----- Original Message ----- From: "Jordi 'IlMaestro' Ministral" <jmi...@or...> To: <dyn...@li...> Sent: Thursday, January 11, 2001 1:12 PM Subject: Re: [Dynapi-Dev] CVS updated > I'm missing events... did I screw something ? First I thought but then going back to the latest code ( > before my modifications ) I am missing those same events. Ohh please just a little luck from time to > time !!!!! > > In NS you can apply the same "for (each image in doc) img.lyrobj = myself" event trick to the links > array. > > > Jordi 'IlMaestro' Ministral wrote: > > > I have updated CVS with a new events.js that should fix IEs event problems. All the example files > > worked fine. This is what happened ( at least this is something I found, maybe there are still > > other issues ): > > > > - All browser events in DynAPI are captured and passed to the same EventMethod. This eventMethod > > identifyes the physical layer, cancels browser event, searches for the appropiate DynmLayer object > > and invokes its event. > > > > - In IE, in order to access the DynLayer object we use the lyrobj property of the DIV itself. This > > property is set when creating a layer so from code executed within the DIV's scope we can still get > > to our DynLayer obj. The problem with our contents was that when clicking on a text, most of the > > times the srcElement of the event was not the DIV but a FONT, TD, TR, TABLE, UL,... element. That > > element did not have a pointer to the dynlayer and thus the API could not route the event properly. > > > > - This issue was partially solved for images by doing: > > > > if (is.ie) for (i in dlyr.elm.all.tags("img")) dlyr.elm.all.tags("img")[i].lyrobj=dlyr; > > > > So images had a pointer to the layer aswell. This we would have needed to do to all elements in our > > content, somethig really painful. Instead, I added this line inside eventmethod. > > > > for(;is.ie && !realsrc.lyrobj && realsrc.parentElement && > > realsrc.parentElement!=realsrc;realsrc=realsrc.parentElement); > > > > Which actually makes realsrc travel IE's object hierarchy until we find the lyrobj reference. By > > doing so I fixed events in IE5 and 5.5. I'm not that sure everything is fine now, but it is an > > improvement. > > > > There are several lines in that method such as that > > > > if (e.type=="mouseover" || e.type=="mouseout") return false; > > > > just before the bubbleEvent() call that I don't understand but I prefer not to touch them. > > > > By the way, it seems that when clicking on a selectable text, NS does not fire a click event. > > Mousedown and mouseup are fired, but click isn't. We could fire it manually but then when clicking > > outside a text we would get two onclicks. > > > > Tell me if I broke something. Sure I did. > > > > Cya > > > > _______________________________________________ > > Dynapi-Dev mailing list > > Dyn...@li... > > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev > ____________________________________________________________ > Get your free domain name and domain-based e-mail from > Namezero.com. New! Namezero Plus domains now available. > Find out more at: http://www.namezero.com > |
|
From: Jordi 'I. M. <jmi...@or...> - 2001-01-10 13:10:51
|
Again one must eat its own words: of course the click event is called correctly
because it is a native browser event. That code was meant for some platforms
where the mouseup was not followed by a onclick.
I don't like being wrong. :(
Jordi 'IlMaestro' Ministral wrote:
> I'm trying to fix the label and button widgets in the hope that this will
> lead to fix many other bugs. Now, tracking down one of these pestering
> event-not-happening bugs I've reached this place inside event.js
>
> if (is.ns4 && is.platform=="other" && type=="mouseup")
> this.invokeEvent("click",e);
>
> I'm reasonabily sure that this -is.platform- condition should not be there.
> Coded that way, click events only fire when you're running a Linux/Unix
> Netscape, don't they ? By removing the condition, the button widget worked
> fine in NS( did you notice that clicking the text in the button was causing
> the button to animate but the resizing did not happen ? ). IE, as Pascal
> already stated, has another problem.
>
|
|
From: Raymond S. <dst...@or...> - 2001-01-10 10:18:37
|
Currently, there are not alot of good representations of precreate in the widgets. The ButtonImage doesn't use it and doesn't work in IE or NS. Others say they will be updated. The only technical writing on it can be found in your docs and build for Dynacore or one prior post from Dan on 'lots of changes'. All the docs here date back to November and the last time you updated them. The viewport is a child layer, maybe that explains why the events don't fire. Yet the images in the widget themselves change. The event related to the viewport isn't even part of a widget, but defined in the onLoad() section of the webpage. Eventually enough will leach out (or in) that I will understand it. Cheers |
|
From: Jordi 'I. M. <jmi...@or...> - 2001-01-11 12:49:20
|
I'm discovering lots of things about the event model now that we have the precreation code. I don't really
know if it has always been the same but I never realized.
If you could just have a little patience I think I can beat it.
Jordi 'IlMaestro' Ministral wrote:
> I'm missing events... did I screw something ? First I thought but then going back to the latest code (
> before my modifications ) I am missing those same events. Ohh please just a little luck from time to
> time !!!!!
>
> In NS you can apply the same "for (each image in doc) img.lyrobj = myself" event trick to the links
> array.
>
> Jordi 'IlMaestro' Ministral wrote:
>
> > I have updated CVS with a new events.js that should fix IEs event problems. All the example files
> > worked fine. This is what happened ( at least this is something I found, maybe there are still
> > other issues ):
> >
> > - All browser events in DynAPI are captured and passed to the same EventMethod. This eventMethod
> > identifyes the physical layer, cancels browser event, searches for the appropiate DynmLayer object
> > and invokes its event.
> >
> > - In IE, in order to access the DynLayer object we use the lyrobj property of the DIV itself. This
> > property is set when creating a layer so from code executed within the DIV's scope we can still get
> > to our DynLayer obj. The problem with our contents was that when clicking on a text, most of the
> > times the srcElement of the event was not the DIV but a FONT, TD, TR, TABLE, UL,... element. That
> > element did not have a pointer to the dynlayer and thus the API could not route the event properly.
> >
> > - This issue was partially solved for images by doing:
> >
> > if (is.ie) for (i in dlyr.elm.all.tags("img")) dlyr.elm.all.tags("img")[i].lyrobj=dlyr;
> >
> > So images had a pointer to the layer aswell. This we would have needed to do to all elements in our
> > content, somethig really painful. Instead, I added this line inside eventmethod.
> >
> > for(;is.ie && !realsrc.lyrobj && realsrc.parentElement &&
> > realsrc.parentElement!=realsrc;realsrc=realsrc.parentElement);
> >
> > Which actually makes realsrc travel IE's object hierarchy until we find the lyrobj reference. By
> > doing so I fixed events in IE5 and 5.5. I'm not that sure everything is fine now, but it is an
> > improvement.
> >
> > There are several lines in that method such as that
> >
> > if (e.type=="mouseover" || e.type=="mouseout") return false;
> >
> > just before the bubbleEvent() call that I don't understand but I prefer not to touch them.
> >
> > By the way, it seems that when clicking on a selectable text, NS does not fire a click event.
> > Mousedown and mouseup are fired, but click isn't. We could fire it manually but then when clicking
> > outside a text we would get two onclicks.
> >
> > Tell me if I broke something. Sure I did.
> >
> > Cya
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
|
|
From: Jordi 'I. M. <jmi...@or...> - 2001-01-11 16:18:55
|
I think I'm almost there this time. The fix I posted on CVS was OK, but was not enought. It seems that adding
a listener before the layer is added to the document causes mouseover events to get lost. Click events work,
though.
Weird as usual
Jordi 'IlMaestro' Ministral wrote:
> I'm discovering lots of things about the event model now that we have the precreation code. I don't really
> know if it has always been the same but I never realized.
>
> If you could just have a little patience I think I can beat it.
>
> Jordi 'IlMaestro' Ministral wrote:
>
> > I'm missing events... did I screw something ? First I thought but then going back to the latest code (
> > before my modifications ) I am missing those same events. Ohh please just a little luck from time to
> > time !!!!!
> >
> > In NS you can apply the same "for (each image in doc) img.lyrobj = myself" event trick to the links
> > array.
> >
> > Jordi 'IlMaestro' Ministral wrote:
> >
> > > I have updated CVS with a new events.js that should fix IEs event problems. All the example files
> > > worked fine. This is what happened ( at least this is something I found, maybe there are still
> > > other issues ):
> > >
> > > - All browser events in DynAPI are captured and passed to the same EventMethod. This eventMethod
> > > identifyes the physical layer, cancels browser event, searches for the appropiate DynmLayer object
> > > and invokes its event.
> > >
> > > - In IE, in order to access the DynLayer object we use the lyrobj property of the DIV itself. This
> > > property is set when creating a layer so from code executed within the DIV's scope we can still get
> > > to our DynLayer obj. The problem with our contents was that when clicking on a text, most of the
> > > times the srcElement of the event was not the DIV but a FONT, TD, TR, TABLE, UL,... element. That
> > > element did not have a pointer to the dynlayer and thus the API could not route the event properly.
> > >
> > > - This issue was partially solved for images by doing:
> > >
> > > if (is.ie) for (i in dlyr.elm.all.tags("img")) dlyr.elm.all.tags("img")[i].lyrobj=dlyr;
> > >
> > > So images had a pointer to the layer aswell. This we would have needed to do to all elements in our
> > > content, somethig really painful. Instead, I added this line inside eventmethod.
> > >
> > > for(;is.ie && !realsrc.lyrobj && realsrc.parentElement &&
> > > realsrc.parentElement!=realsrc;realsrc=realsrc.parentElement);
> > >
> > > Which actually makes realsrc travel IE's object hierarchy until we find the lyrobj reference. By
> > > doing so I fixed events in IE5 and 5.5. I'm not that sure everything is fine now, but it is an
> > > improvement.
> > >
> > > There are several lines in that method such as that
> > >
> > > if (e.type=="mouseover" || e.type=="mouseout") return false;
> > >
> > > just before the bubbleEvent() call that I don't understand but I prefer not to touch them.
> > >
> > > By the way, it seems that when clicking on a selectable text, NS does not fire a click event.
> > > Mousedown and mouseup are fired, but click isn't. We could fire it manually but then when clicking
> > > outside a text we would get two onclicks.
> > >
> > > Tell me if I broke something. Sure I did.
> > >
> > > Cya
> > >
> > > _______________________________________________
> > > Dynapi-Dev mailing list
> > > Dyn...@li...
> > > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
|
|
From: Jordi 'I. M. <jmi...@or...> - 2001-01-11 18:07:41
|
Ok, eventlisteners can be added before layer creation again. Looks that I got IE5.5 to obey me as a marine, ( yes
sir i'm a piece o'shit sir !! ) and now I only need to fix some stupid NS issues. Maybe I did cause some of these
errors myself while fixing others but anyway.
I'm commented out these lines:
if (e.type=="mouseout" && this.contains(e.toElement)) return true;
if (e.type=="mouseover" && this.contains(e.fromElement)) { return true; }
which were causing trouble. If they need to be there please the author tell me why. I can't think of any
circunstance where they should be in there.
Jordi 'IlMaestro' Ministral wrote:
> I think I'm almost there this time. The fix I posted on CVS was OK, but was not enought. It seems that adding
> a listener before the layer is added to the document causes mouseover events to get lost. Click events work,
> though.
>
> Weird as usual
>
> Jordi 'IlMaestro' Ministral wrote:
>
> > I'm discovering lots of things about the event model now that we have the precreation code. I don't really
> > know if it has always been the same but I never realized.
> >
> > If you could just have a little patience I think I can beat it.
> >
> > Jordi 'IlMaestro' Ministral wrote:
> >
> > > I'm missing events... did I screw something ? First I thought but then going back to the latest code (
> > > before my modifications ) I am missing those same events. Ohh please just a little luck from time to
> > > time !!!!!
> > >
> > > In NS you can apply the same "for (each image in doc) img.lyrobj = myself" event trick to the links
> > > array.
> > >
> > > Jordi 'IlMaestro' Ministral wrote:
> > >
> > > > I have updated CVS with a new events.js that should fix IEs event problems. All the example files
> > > > worked fine. This is what happened ( at least this is something I found, maybe there are still
> > > > other issues ):
> > > >
> > > > - All browser events in DynAPI are captured and passed to the same EventMethod. This eventMethod
> > > > identifyes the physical layer, cancels browser event, searches for the appropiate DynmLayer object
> > > > and invokes its event.
> > > >
> > > > - In IE, in order to access the DynLayer object we use the lyrobj property of the DIV itself. This
> > > > property is set when creating a layer so from code executed within the DIV's scope we can still get
> > > > to our DynLayer obj. The problem with our contents was that when clicking on a text, most of the
> > > > times the srcElement of the event was not the DIV but a FONT, TD, TR, TABLE, UL,... element. That
> > > > element did not have a pointer to the dynlayer and thus the API could not route the event properly.
> > > >
> > > > - This issue was partially solved for images by doing:
> > > >
> > > > if (is.ie) for (i in dlyr.elm.all.tags("img")) dlyr.elm.all.tags("img")[i].lyrobj=dlyr;
> > > >
> > > > So images had a pointer to the layer aswell. This we would have needed to do to all elements in our
> > > > content, somethig really painful. Instead, I added this line inside eventmethod.
> > > >
> > > > for(;is.ie && !realsrc.lyrobj && realsrc.parentElement &&
> > > > realsrc.parentElement!=realsrc;realsrc=realsrc.parentElement);
> > > >
> > > > Which actually makes realsrc travel IE's object hierarchy until we find the lyrobj reference. By
> > > > doing so I fixed events in IE5 and 5.5. I'm not that sure everything is fine now, but it is an
> > > > improvement.
> > > >
> > > > There are several lines in that method such as that
> > > >
> > > > if (e.type=="mouseover" || e.type=="mouseout") return false;
> > > >
> > > > just before the bubbleEvent() call that I don't understand but I prefer not to touch them.
> > > >
> > > > By the way, it seems that when clicking on a selectable text, NS does not fire a click event.
> > > > Mousedown and mouseup are fired, but click isn't. We could fire it manually but then when clicking
> > > > outside a text we would get two onclicks.
> > > >
> > > > Tell me if I broke something. Sure I did.
> > > >
> > > > Cya
> > > >
> > > > _______________________________________________
> > > > Dynapi-Dev mailing list
> > > > Dyn...@li...
> > > > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> > >
> > > _______________________________________________
> > > Dynapi-Dev mailing list
> > > Dyn...@li...
> > > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
|
|
From: Jordi 'I. M. <jmi...@or...> - 2001-01-11 19:21:36
|
OK. This is the status of the events: I think they all work now but there is one case: imagine layer a, layerb child
of a and layer c child of b. All children are 0,0 placed so there's a common corner. Now do a mouseover on that
corner. What happens ?
IE sends the mouseover event only to the upper-most layer, that's 'c'. Then the API kicks in and bubbles it if you
allowed it to bubble. Everything works as expected. Now let's see what does netscape do: well all layers receive
their own mouseover event. It makes sense somehow because all layers were enetered by the mouse. Having this in mind,
the EventMethod does not bubble mouseover and mouseouts in NS because they will already be sent to the other layers,
then introciing this line at the end of Eventmethod (just before bubbling):
if (is.ns && (e.type=="mouseover" || e.type=="mouseout")) return false;
That is.ns was introduced by me because it was blocking IEs events (remember rollovers not happening in some menu
widgets ? )
But the events are received by layers from parent to child, not child to parent as we'd want. Therefore mouseovers
work in a different way IE-NS. What we should do is cancel a parent's mouseovers-mouseouts if we detect that that
same event affected one childlayer and have the child most inside of the hierarchy that received that mouseover
execute it and bubble it up.
I'm braindead, maybe tommorrow. I'll update CVS with what I have so far. Use at your own risk but it should be the
best version to date.
PS: I understood those lines:
if (e.type=="mouseout" && this.contains(e.toElement)) return true;
if (e.type=="mouseover" && this.contains(e.fromElement)) return true;
They must be there.
Jordi 'IlMaestro' Ministral wrote:
> Ok, eventlisteners can be added before layer creation again. Looks that I got IE5.5 to obey me as a marine, ( yes
> sir i'm a piece o'shit sir !! ) and now I only need to fix some stupid NS issues. Maybe I did cause some of these
> errors myself while fixing others but anyway.
>
> I'm commented out these lines:
>
> if (e.type=="mouseout" && this.contains(e.toElement)) return true;
> if (e.type=="mouseover" && this.contains(e.fromElement)) { return true; }
>
> which were causing trouble. If they need to be there please the author tell me why. I can't think of any
> circunstance where they should be in there.
>
> Jordi 'IlMaestro' Ministral wrote:
>
> > I think I'm almost there this time. The fix I posted on CVS was OK, but was not enought. It seems that adding
> > a listener before the layer is added to the document causes mouseover events to get lost. Click events work,
> > though.
> >
> > Weird as usual
> >
> > Jordi 'IlMaestro' Ministral wrote:
> >
> > > I'm discovering lots of things about the event model now that we have the precreation code. I don't really
> > > know if it has always been the same but I never realized.
> > >
> > > If you could just have a little patience I think I can beat it.
> > >
> > > Jordi 'IlMaestro' Ministral wrote:
> > >
> > > > I'm missing events... did I screw something ? First I thought but then going back to the latest code (
> > > > before my modifications ) I am missing those same events. Ohh please just a little luck from time to
> > > > time !!!!!
> > > >
> > > > In NS you can apply the same "for (each image in doc) img.lyrobj = myself" event trick to the links
> > > > array.
> > > >
> > > > Jordi 'IlMaestro' Ministral wrote:
> > > >
> > > > > I have updated CVS with a new events.js that should fix IEs event problems. All the example files
> > > > > worked fine. This is what happened ( at least this is something I found, maybe there are still
> > > > > other issues ):
> > > > >
> > > > > - All browser events in DynAPI are captured and passed to the same EventMethod. This eventMethod
> > > > > identifyes the physical layer, cancels browser event, searches for the appropiate DynmLayer object
> > > > > and invokes its event.
> > > > >
> > > > > - In IE, in order to access the DynLayer object we use the lyrobj property of the DIV itself. This
> > > > > property is set when creating a layer so from code executed within the DIV's scope we can still get
> > > > > to our DynLayer obj. The problem with our contents was that when clicking on a text, most of the
> > > > > times the srcElement of the event was not the DIV but a FONT, TD, TR, TABLE, UL,... element. That
> > > > > element did not have a pointer to the dynlayer and thus the API could not route the event properly.
> > > > >
> > > > > - This issue was partially solved for images by doing:
> > > > >
> > > > > if (is.ie) for (i in dlyr.elm.all.tags("img")) dlyr.elm.all.tags("img")[i].lyrobj=dlyr;
> > > > >
> > > > > So images had a pointer to the layer aswell. This we would have needed to do to all elements in our
> > > > > content, somethig really painful. Instead, I added this line inside eventmethod.
> > > > >
> > > > > for(;is.ie && !realsrc.lyrobj && realsrc.parentElement &&
> > > > > realsrc.parentElement!=realsrc;realsrc=realsrc.parentElement);
> > > > >
> > > > > Which actually makes realsrc travel IE's object hierarchy until we find the lyrobj reference. By
> > > > > doing so I fixed events in IE5 and 5.5. I'm not that sure everything is fine now, but it is an
> > > > > improvement.
> > > > >
> > > > > There are several lines in that method such as that
> > > > >
> > > > > if (e.type=="mouseover" || e.type=="mouseout") return false;
> > > > >
> > > > > just before the bubbleEvent() call that I don't understand but I prefer not to touch them.
> > > > >
> > > > > By the way, it seems that when clicking on a selectable text, NS does not fire a click event.
> > > > > Mousedown and mouseup are fired, but click isn't. We could fire it manually but then when clicking
> > > > > outside a text we would get two onclicks.
> > > > >
> > > > > Tell me if I broke something. Sure I did.
> > > > >
> > > > > Cya
> > > > >
> > > > > _______________________________________________
> > > > > Dynapi-Dev mailing list
> > > > > Dyn...@li...
> > > > > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> > > >
> > > > _______________________________________________
> > > > Dynapi-Dev mailing list
> > > > Dyn...@li...
> > > > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> > >
> > > _______________________________________________
> > > Dynapi-Dev mailing list
> > > Dyn...@li...
> > > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
|
|
From: Jordi 'I. M. <jmi...@or...> - 2001-01-18 12:58:03
|
While I was in the middle of my personal war with events my mail server stoped working. Since thursday night I have not received any mail, and I won't receive all the missed ones now. I don't know what's been happening here but anyway: I've kept on debugging events and layer creation. I just updated CVS with the latest files, which fix several bugs I found. I also added a new example file, dynapi.api.bubbling.html, which allows to test event bubbling. Please bear with me If I broke something. The tests I've carried so far look Ok. I'm developing a huge business web using DynAPI ( we're talking about 500+ deep-nested layers ) and trying to optimize as much as I can, then I'm finding all existing bugs. Cya |
×
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