Menu
▾
▴
dynapi-dev
|
From: <no...@so...> - 2001-01-10 08:30:24
|
Bug #128263, was updated on 2001-Jan-10 00:30
Here is a current snapshot of the bug.
Project: DynAPI 2
Category: API Extentions
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: marstr
Assigned to : nobody
Summary: PathAnimation.stopAnimation() bug (& patch)
Details: dynapi/util/pathanim.js
a bug in PathAnimation.stopAnimation() causes the onpathstop-event to fire
before some values were set
(this.playing=false)
before you couldn't slide a DynLayer directly in a
onpathstop eventListener (while this.playing still
was true)
i've moved the line
if (this.dlyr != null) this.dlyr.invokeEvent("pathstop");
last in the method which solved the problem
PathAnimation.prototype.stopAnimation = function () {
if (this.pathPlaying && this.pathPlaying.resets && !this.cancelThread &&
this.dlyr!=null)
this.dlyr.moveTo(this.pathPlaying[0],this.pathPlaying[1]);
this.stop();
delete this.pathPlaying; // only deletes unstored path
this.playing = false;
if (this.dlyr != null) this.dlyr.invokeEvent("pathstop");
};
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=128263&group_id=5757
|
|
From: <no...@so...> - 2001-01-10 10:26:56
|
Bug #128263, was updated on 2001-Jan-10 00:30
Here is a current snapshot of the bug.
Project: DynAPI 2
Category: API Extentions
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: marstr
Assigned to : nobody
Summary: PathAnimation.stopAnimation() bug (& patch)
Details: dynapi/util/pathanim.js
a bug in PathAnimation.stopAnimation() causes the onpathstop-event to fire
before some values were set
(this.playing=false)
before you couldn't slide a DynLayer directly in a
onpathstop eventListener (while this.playing still
was true)
i've moved the line
if (this.dlyr != null) this.dlyr.invokeEvent("pathstop");
last in the method which solved the problem
PathAnimation.prototype.stopAnimation = function () {
if (this.pathPlaying && this.pathPlaying.resets && !this.cancelThread &&
this.dlyr!=null)
this.dlyr.moveTo(this.pathPlaying[0],this.pathPlaying[1]);
this.stop();
delete this.pathPlaying; // only deletes unstored path
this.playing = false;
if (this.dlyr != null) this.dlyr.invokeEvent("pathstop");
};
Follow-Ups:
Date: 2001-Jan-10 02:27
By: nobody
Comment:
Hi,
I'm glad to see pathanim tackled at last.What you're sayng is correct, and
is what I did in my modified pathanim (see:
http://www.resass.f2s.com/?menu=examples&node=1 or
http://www.richardinfo.f2s.com/?menu=examples&node=1
under "dynapi.util.pathanim.chained.html" when the servers up again)
But I also had to add the method stopAnimation now() , which is identical,
but without
invoke-ing pathstop, so the animation could be manually halted without
starting the next one from the onpathstop listener:
PathAnimation.prototype.stopAnimationNow = function () {
if (this.pathPlaying && this.pathPlaying.resets && !this.cancelThread &&
this.dlyr!=null)
this.dlyr.moveTo(this.pathPlaying[0],this.pathPlaying[1]);
this.stop();
delete this.pathPlaying; // only deletes unstored path
this.playing = false;
};
And I don't understand why slideBy() has been scrapped just because you
can do that manually aswell; you can do most of the
API manually, but it's easier if you can just call a method. And we still
use moveBy(), so slideBy() keeps consistency, and saves changing existing
webcode when you upgrade you're API.
DynLayer.prototype.slideBy = function(x,y,inc,ms) {
if (x==null) x = 0;
if (y==null) y = 0;
this.slideTo(this.x+x,this.y+y,inc,ms);
};
Cheers,
Richard :o
ma...@ri...
www.richardinfo.com
(Everything running on, and ported to the 19/12/2000 snapshot of DynAPI2)
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=128263&group_id=5757
|
|
From: <no...@so...> - 2001-01-25 21:08:42
|
Bug #128263, was updated on 2001-Jan-10 00:30
Here is a current snapshot of the bug.
Project: DynAPI 2
Category: API Extentions
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: marstr
Assigned to : nobody
Summary: PathAnimation.stopAnimation() bug (& patch)
Details: dynapi/util/pathanim.js
a bug in PathAnimation.stopAnimation() causes the onpathstop-event to fire
before some values were set
(this.playing=false)
before you couldn't slide a DynLayer directly in a
onpathstop eventListener (while this.playing still
was true)
i've moved the line
if (this.dlyr != null) this.dlyr.invokeEvent("pathstop");
last in the method which solved the problem
PathAnimation.prototype.stopAnimation = function () {
if (this.pathPlaying && this.pathPlaying.resets && !this.cancelThread &&
this.dlyr!=null)
this.dlyr.moveTo(this.pathPlaying[0],this.pathPlaying[1]);
this.stop();
delete this.pathPlaying; // only deletes unstored path
this.playing = false;
if (this.dlyr != null) this.dlyr.invokeEvent("pathstop");
};
Follow-Ups:
Date: 2001-Jan-25 13:09
By: rainwater
Comment:
Its been implemented in CVS.
-------------------------------------------------------
Date: 2001-Jan-10 02:27
By: nobody
Comment:
Hi,
I'm glad to see pathanim tackled at last.What you're sayng is correct, and
is what I did in my modified pathanim (see:
http://www.resass.f2s.com/?menu=examples&node=1 or
http://www.richardinfo.f2s.com/?menu=examples&node=1
under "dynapi.util.pathanim.chained.html" when the servers up again)
But I also had to add the method stopAnimation now() , which is identical,
but without
invoke-ing pathstop, so the animation could be manually halted without
starting the next one from the onpathstop listener:
PathAnimation.prototype.stopAnimationNow = function () {
if (this.pathPlaying && this.pathPlaying.resets && !this.cancelThread &&
this.dlyr!=null)
this.dlyr.moveTo(this.pathPlaying[0],this.pathPlaying[1]);
this.stop();
delete this.pathPlaying; // only deletes unstored path
this.playing = false;
};
And I don't understand why slideBy() has been scrapped just because you
can do that manually aswell; you can do most of the
API manually, but it's easier if you can just call a method. And we still
use moveBy(), so slideBy() keeps consistency, and saves changing existing
webcode when you upgrade you're API.
DynLayer.prototype.slideBy = function(x,y,inc,ms) {
if (x==null) x = 0;
if (y==null) y = 0;
this.slideTo(this.x+x,this.y+y,inc,ms);
};
Cheers,
Richard :o
ma...@ri...
www.richardinfo.com
(Everything running on, and ported to the 19/12/2000 snapshot of DynAPI2)
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=128263&group_id=5757
|
|
From: Richard :o <ma...@ri...> - 2001-01-10 10:32:08
|
Hi, I'm glad to see pathanim tackled at last.What you're sayng is correct, and is what I did in my modified pathanim (see: http://www.resass.f2s.com/?menu=examples&node=1 or http://www.richardinfo.f2s.com/?menu=examples&node=1 under "dynapi.util.pathanim.chained.html" when the servers up again) But I also had to add the method stopAnimation now() , which is identical, but without invoke-ing pathstop, so the animation could be manually halted without starting the next one from the onpathstop listener: PathAnimation.prototype.stopAnimationNow = function () { if (this.pathPlaying && this.pathPlaying.resets && !this.cancelThread && this.dlyr!=null) this.dlyr.moveTo(this.pathPlaying[0],this.pathPlaying[1]); this.stop(); delete this.pathPlaying; // only deletes unstored path this.playing = false; }; And I don't understand why slideBy() has been scrapped just because you can do that manually aswell; you can do most of the API manually, but it's easier if you can just call a method. And we still use moveBy(), so slideBy() keeps consistency, and saves changing existing webcode when you upgrade you're API. DynLayer.prototype.slideBy = function(x,y,inc,ms) { if (x==null) x = 0; if (y==null) y = 0; this.slideTo(this.x+x,this.y+y,inc,ms); }; Cheers, Richard :o ma...@ri... www.richardinfo.com (Everything running on, and ported to the 19/12/2000 snapshot of DynAPI2) ----- Original Message ----- From: <no...@so...> To: <ma...@ab...>; <no...@so...>; <dyn...@so...> Sent: Wednesday, January 10, 2001 9:30 AM Subject: [Dynapi-Dev] [Bug #128263] PathAnimation.stopAnimation() bug (& patch) > Bug #128263, was updated on 2001-Jan-10 00:30 > Here is a current snapshot of the bug. > > Project: DynAPI 2 > Category: API Extentions > Status: Open > Resolution: None > Bug Group: None > Priority: 5 > Submitted by: marstr > Assigned to : nobody > Summary: PathAnimation.stopAnimation() bug (& patch) > > Details: dynapi/util/pathanim.js > > a bug in PathAnimation.stopAnimation() causes the onpathstop-event to fire > before some values were set > (this.playing=false) > before you couldn't slide a DynLayer directly in a > onpathstop eventListener (while this.playing still > was true) > > i've moved the line > if (this.dlyr != null) this.dlyr.invokeEvent("pathstop"); > > last in the method which solved the problem > > PathAnimation.prototype.stopAnimation = function () { > if (this.pathPlaying && this.pathPlaying.resets && !this.cancelThread && > this.dlyr!=null) > this.dlyr.moveTo(this.pathPlaying[0],this.pathPlaying[1]); > this.stop(); > delete this.pathPlaying; // only deletes unstored path > this.playing = false; > if (this.dlyr != null) this.dlyr.invokeEvent("pathstop"); > }; > > For detailed info, follow this link: > http://sourceforge.net/bugs/?func=detailbug&bug_id=128263&group_id=5757 > > _______________________________________________ > 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: Raymond S. <dst...@or...> - 2001-01-10 10:37:19
|
I'm for including the 'PathAnimation.prototype.stopAnimationNow ' method Richard discussed. If your doing chained animations that lead to other events it's a must have. Or the whole thing repeats again. ----- Original Message ----- From: "Richard :o" <ma...@ri...> To: <dyn...@li...> Sent: Tuesday, January 09, 2001 2:32 AM Subject: Re: [Dynapi-Dev] [Bug #128263] PathAnimation.stopAnimation() bug (& patch) > Hi, > I'm glad to see pathanim tackled at last.What you're sayng is correct, and > is what I did in my modified pathanim (see: > http://www.resass.f2s.com/?menu=examples&node=1 or > http://www.richardinfo.f2s.com/?menu=examples&node=1 > under "dynapi.util.pathanim.chained.html" when the servers up again) > > But I also had to add the method stopAnimation now() , which is identical, > but without > invoke-ing pathstop, so the animation could be manually halted without > starting the next one from the onpathstop listener: > > PathAnimation.prototype.stopAnimationNow = function () { > if (this.pathPlaying && this.pathPlaying.resets && !this.cancelThread && > this.dlyr!=null) this.dlyr.moveTo(this.pathPlaying[0],this.pathPlaying[1]); > this.stop(); > delete this.pathPlaying; // only deletes unstored path > this.playing = false; > }; > And I don't understand why slideBy() has been scrapped just because you can > do that manually aswell; you can do most of the > API manually, but it's easier if you can just call a method. And we still > use moveBy(), so slideBy() keeps consistency, and saves changing existing > webcode when you upgrade you're API. > > DynLayer.prototype.slideBy = function(x,y,inc,ms) { > if (x==null) x = 0; > if (y==null) y = 0; > this.slideTo(this.x+x,this.y+y,inc,ms); > }; > > Cheers, > Richard :o > > ma...@ri... > www.richardinfo.com > (Everything running on, and ported to the 19/12/2000 snapshot of DynAPI2) > > ----- Original Message ----- > From: <no...@so...> > To: <ma...@ab...>; <no...@so...>; > <dyn...@so...> > Sent: Wednesday, January 10, 2001 9:30 AM > Subject: [Dynapi-Dev] [Bug #128263] PathAnimation.stopAnimation() bug (& > patch) > > > > Bug #128263, was updated on 2001-Jan-10 00:30 > > Here is a current snapshot of the bug. > > > > Project: DynAPI 2 > > Category: API Extentions > > Status: Open > > Resolution: None > > Bug Group: None > > Priority: 5 > > Submitted by: marstr > > Assigned to : nobody > > Summary: PathAnimation.stopAnimation() bug (& patch) > > > > Details: dynapi/util/pathanim.js > > > > a bug in PathAnimation.stopAnimation() causes the onpathstop-event to fire > > before some values were set > > (this.playing=false) > > before you couldn't slide a DynLayer directly in a > > onpathstop eventListener (while this.playing still > > was true) > > > > i've moved the line > > if (this.dlyr != null) this.dlyr.invokeEvent("pathstop"); > > > > last in the method which solved the problem > > > > PathAnimation.prototype.stopAnimation = function () { > > if (this.pathPlaying && this.pathPlaying.resets && !this.cancelThread && > > this.dlyr!=null) > > this.dlyr.moveTo(this.pathPlaying[0],this.pathPlaying[1]); > > this.stop(); > > delete this.pathPlaying; // only deletes unstored path > > this.playing = false; > > if (this.dlyr != null) this.dlyr.invokeEvent("pathstop"); > > }; > > > > For detailed info, follow this link: > > http://sourceforge.net/bugs/?func=detailbug&bug_id=128263&group_id=5757 > > > > _______________________________________________ > > 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 > > > > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev > |
|
From: <ma...@ab...> - 2001-01-10 11:10:09
|
wouldn't it be better to add a noevt-parameter to stopAnimation():
PathAnimation.prototype.stopAnimation = function (noevt) {
if (this.pathPlaying && this.pathPlaying.resets && !this.cancelThread &&
this.dlyr!=null) this.dlyr.moveTo(this.pathPlaying[0],this.pathPlaying[1]);
this.stop();
delete this.pathPlaying; // only deletes unstored path
this.playing = false;
if (this.dlyr != null && noevt!=false) this.dlyr.invokeEvent("pathstop");
};
and maybe use stopAnimationNow() just to do a stopAnimation(false) -call
PathAnimation.prototype.stopAnimationNow=function() {
this.stopAnimation(false);
}
/mrtin
> -----Original Message-----
> From: dyn...@li...
> [mailto:dyn...@li...]On Behalf Of Raymond
> Smith
> Sent: den 10 januari 2001 11:36
> To: dyn...@li...
> Subject: Re: [Dynapi-Dev] [Bug #128263] PathAnimation.stopAnimation()
> bug (& patch)
>
>
> I'm for including the 'PathAnimation.prototype.stopAnimationNow ' method
> Richard discussed. If your doing chained animations that lead to other
> events it's a must have. Or the whole thing repeats again.
>
>
> ----- Original Message -----
> From: "Richard :o" <ma...@ri...>
> To: <dyn...@li...>
> Sent: Tuesday, January 09, 2001 2:32 AM
> Subject: Re: [Dynapi-Dev] [Bug #128263]
> PathAnimation.stopAnimation() bug (&
> patch)
>
>
> > Hi,
> > I'm glad to see pathanim tackled at last.What you're sayng is
> correct, and
> > is what I did in my modified pathanim (see:
> > http://www.resass.f2s.com/?menu=examples&node=1 or
> > http://www.richardinfo.f2s.com/?menu=examples&node=1
> > under "dynapi.util.pathanim.chained.html" when the servers up again)
> >
> > But I also had to add the method stopAnimation now() , which is
> identical,
> > but without
> > invoke-ing pathstop, so the animation could be manually halted without
> > starting the next one from the onpathstop listener:
> >
> > PathAnimation.prototype.stopAnimationNow = function () {
> > if (this.pathPlaying && this.pathPlaying.resets &&
> !this.cancelThread &&
> > this.dlyr!=null)
> this.dlyr.moveTo(this.pathPlaying[0],this.pathPlaying[1]);
> > this.stop();
> > delete this.pathPlaying; // only deletes unstored path
> > this.playing = false;
> > };
> > And I don't understand why slideBy() has been scrapped just because you
> can
> > do that manually aswell; you can do most of the
> > API manually, but it's easier if you can just call a method.
> And we still
> > use moveBy(), so slideBy() keeps consistency, and saves
> changing existing
> > webcode when you upgrade you're API.
> >
> > DynLayer.prototype.slideBy = function(x,y,inc,ms) {
> > if (x==null) x = 0;
> > if (y==null) y = 0;
> > this.slideTo(this.x+x,this.y+y,inc,ms);
> > };
> >
> > Cheers,
> > Richard :o
> >
> > ma...@ri...
> > www.richardinfo.com
> > (Everything running on, and ported to the 19/12/2000 snapshot
> of DynAPI2)
> >
> > ----- Original Message -----
> > From: <no...@so...>
> > To: <ma...@ab...>; <no...@so...>;
> > <dyn...@so...>
> > Sent: Wednesday, January 10, 2001 9:30 AM
> > Subject: [Dynapi-Dev] [Bug #128263] PathAnimation.stopAnimation() bug (&
> > patch)
> >
> >
> > > Bug #128263, was updated on 2001-Jan-10 00:30
> > > Here is a current snapshot of the bug.
> > >
> > > Project: DynAPI 2
> > > Category: API Extentions
> > > Status: Open
> > > Resolution: None
> > > Bug Group: None
> > > Priority: 5
> > > Submitted by: marstr
> > > Assigned to : nobody
> > > Summary: PathAnimation.stopAnimation() bug (& patch)
> > >
> > > Details: dynapi/util/pathanim.js
> > >
> > > a bug in PathAnimation.stopAnimation() causes the onpathstop-event to
> fire
> > > before some values were set
> > > (this.playing=false)
> > > before you couldn't slide a DynLayer directly in a
> > > onpathstop eventListener (while this.playing still
> > > was true)
> > >
> > > i've moved the line
> > > if (this.dlyr != null) this.dlyr.invokeEvent("pathstop");
> > >
> > > last in the method which solved the problem
> > >
> > > PathAnimation.prototype.stopAnimation = function () {
> > > if (this.pathPlaying && this.pathPlaying.resets &&
> !this.cancelThread &&
> > > this.dlyr!=null)
> > > this.dlyr.moveTo(this.pathPlaying[0],this.pathPlaying[1]);
> > > this.stop();
> > > delete this.pathPlaying; // only deletes unstored path
> > > this.playing = false;
> > > if (this.dlyr != null) this.dlyr.invokeEvent("pathstop");
> > > };
> > >
> > > For detailed info, follow this link:
> > >
http://sourceforge.net/bugs/?func=detailbug&bug_id=128263&group_id=5757
> >
> > _______________________________________________
> > 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
> >
>
>
>
> _______________________________________________
> 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: Michael P. <mp...@ph...> - 2001-01-11 04:00:27
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I'm interested in having two events. A stop and an end event.
Some times, I need to refresh to layer content after a layer has moved
(eg. if it contains a form). Does anyone have any problems with adding
this second event?
<p>martin ström wrote:
<blockquote TYPE=CITE>wouldn't it be better to add a noevt-parameter to
stopAnimation():
<p>PathAnimation.prototype.stopAnimation = function (noevt) {
<br> if (this.pathPlaying &&
this.pathPlaying.resets && !this.cancelThread &&
<br>this.dlyr!=null) this.dlyr.moveTo(this.pathPlaying[0],this.pathPlaying[1]);
<br> this.stop();
<br> delete this.pathPlaying;
// only deletes unstored path
<br> this.playing = false;
<br> if (this.dlyr != null &&
noevt!=false) this.dlyr.invokeEvent("pathstop");
<br>};
<p>and maybe use stopAnimationNow() just to do a stopAnimation(false) -call
<p>PathAnimation.prototype.stopAnimationNow=function() {
<br> this.stopAnimation(false);
<br>}
<p>/mrtin
<p>> -----Original Message-----
<br>> From: dyn...@li...
<br>> [<a href="mailto:dyn...@li...">mailto:dyn...@li...</a>]On
Behalf Of Raymond
<br>> Smith
<br>> Sent: den 10 januari 2001 11:36
<br>> To: dyn...@li...
<br>> Subject: Re: [Dynapi-Dev] [Bug #128263] PathAnimation.stopAnimation()
<br>> bug (& patch)
<br>>
<br>>
<br>> I'm for including the 'PathAnimation.prototype.stopAnimationNow
' method
<br>> Richard discussed. If your doing chained animations that lead
to other
<br>> events it's a must have. Or the whole thing repeats again.
<br>>
<br>>
<br>> ----- Original Message -----
<br>> From: "Richard :o" <ma...@ri...>
<br>> To: <dyn...@li...>
<br>> Sent: Tuesday, January 09, 2001 2:32 AM
<br>> Subject: Re: [Dynapi-Dev] [Bug #128263]
<br>> PathAnimation.stopAnimation() bug (&
<br>> patch)
<br>>
<br>>
<br>> > Hi,
<br>> > I'm glad to see pathanim tackled at last.What you're sayng is
<br>> correct, and
<br>> > is what I did in my modified pathanim (see:
<br>> > <a href="http://www.resass.f2s.com/?menu=examples&node=1">http://www.resass.f2s.com/?menu=examples&node=1</a>
or
<br>> > <a href="http://www.richardinfo.f2s.com/?menu=examples&node=1">http://www.richardinfo.f2s.com/?menu=examples&node=1</a>
<br>> > under "dynapi.util.pathanim.chained.html" when the servers up again)
<br>> >
<br>> > But I also had to add the method stopAnimation now() , which is
<br>> identical,
<br>> > but without
<br>> > invoke-ing pathstop, so the animation could be manually halted
without
<br>> > starting the next one from the onpathstop listener:
<br>> >
<br>> > PathAnimation.prototype.stopAnimationNow = function () {
<br>> > if (this.pathPlaying && this.pathPlaying.resets &&
<br>> !this.cancelThread &&
<br>> > this.dlyr!=null)
<br>> this.dlyr.moveTo(this.pathPlaying[0],this.pathPlaying[1]);
<br>> > this.stop();
<br>> > delete this.pathPlaying; // only deletes unstored path
<br>> > this.playing = false;
<br>> > };
<br>> > And I don't understand why slideBy() has been scrapped just
because you
<br>> can
<br>> > do that manually aswell; you can do most of the
<br>> > API manually, but it's easier if you can just call a method.
<br>> And we still
<br>> > use moveBy(), so slideBy() keeps consistency, and saves
<br>> changing existing
<br>> > webcode when you upgrade you're API.
<br>> >
<br>> > DynLayer.prototype.slideBy = function(x,y,inc,ms) {
<br>> > if (x==null) x = 0;
<br>> > if (y==null) y = 0;
<br>> > this.slideTo(this.x+x,this.y+y,inc,ms);
<br>> > };
<br>> >
<br>> > Cheers,
<br>> > Richard :o
<br>> >
<br>> > ma...@ri...
<br>> > www.richardinfo.com
<br>> > (Everything running on, and ported to the 19/12/2000 snapshot
<br>> of DynAPI2)
<br>> >
<br>> > ----- Original Message -----
<br>> > From: <no...@so...>
<br>> > To: <ma...@ab...>; <no...@so...>;
<br>> > <dyn...@so...>
<br>> > Sent: Wednesday, January 10, 2001 9:30 AM
<br>> > Subject: [Dynapi-Dev] [Bug #128263] PathAnimation.stopAnimation()
bug (&
<br>> > patch)
<br>> >
<br>> >
<br>> > > Bug #128263, was updated on 2001-Jan-10 00:30
<br>> > > Here is a current snapshot of the bug.
<br>> > >
<br>> > > Project: DynAPI 2
<br>> > > Category: API Extentions
<br>> > > Status: Open
<br>> > > Resolution: None
<br>> > > Bug Group: None
<br>> > > Priority: 5
<br>> > > Submitted by: marstr
<br>> > > Assigned to : nobody
<br>> > > Summary: PathAnimation.stopAnimation() bug (& patch)
<br>> > >
<br>> > > Details: dynapi/util/pathanim.js
<br>> > >
<br>> > > a bug in PathAnimation.stopAnimation() causes the onpathstop-event
to
<br>> fire
<br>> > > before some values were set
<br>> > > (this.playing=false)
<br>> > > before you couldn't slide a DynLayer directly in a
<br>> > > onpathstop eventListener (while this.playing still
<br>> > > was true)
<br>> > >
<br>> > > i've moved the line
<br>> > > if (this.dlyr != null) this.dlyr.invokeEvent("pathstop");
<br>> > >
<br>> > > last in the method which solved the problem
<br>> > >
<br>> > > PathAnimation.prototype.stopAnimation = function () {
<br>> > > if (this.pathPlaying && this.pathPlaying.resets &&
<br>> !this.cancelThread &&
<br>> > > this.dlyr!=null)
<br>> > > this.dlyr.moveTo(this.pathPlaying[0],this.pathPlaying[1]);
<br>> > > this.stop();
<br>> > > delete this.pathPlaying; // only deletes unstored path
<br>> > > this.playing = false;
<br>> > > if (this.dlyr != null) this.dlyr.invokeEvent("pathstop");
<br>> > > };
<br>> > >
<br>> > > For detailed info, follow this link:
<br>> > >
<br><a href="http://sourceforge.net/bugs/?func=detailbug&bug_id=128263&group_id=5757">http://sourceforge.net/bugs/?func=detailbug&bug_id=128263&group_id=5757</a>
<br>> >
<br>> > _______________________________________________
<br>> > Dynapi-Dev mailing list
<br>> > Dyn...@li...
<br>> > <a href="http://lists.sourceforge.net/mailman/listinfo/dynapi-dev">http://lists.sourceforge.net/mailman/listinfo/dynapi-dev</a>
<br>> > ____________________________________________________________
<br>> > Get your free domain name and domain-based e-mail from
<br>> > Namezero.com. New! Namezero Plus domains now available.
<br>> > Find out more at: <a href="http://www.namezero.com">http://www.namezero.com</a>
<br>> >
<br>>
<br>>
<br>>
<br>> _______________________________________________
<br>> Dynapi-Dev mailing list
<br>> Dyn...@li...
<br>> <a href="http://lists.sourceforge.net/mailman/listinfo/dynapi-dev">http://lists.sourceforge.net/mailman/listinfo/dynapi-dev</a>
<br>>
<p>_______________________________________________
<br>Dynapi-Dev mailing list
<br>Dyn...@li...
<br><a href="http://lists.sourceforge.net/mailman/listinfo/dynapi-dev">http://lists.sourceforge.net/mailman/listinfo/dynapi-dev</a>
<p>_______________________________________________
<br>Dynapi-Dev mailing list
<br>Dyn...@li...
<br><a href="http://lists.sourceforge.net/mailman/listinfo/dynapi-dev">http://lists.sourceforge.net/mailman/listinfo/dynapi-dev</a></blockquote>
<p>--
<br>Michael Pemberton
<br>mp...@ph...
<br>ICQ: 12107010
<br> </html>
|
|
From: Raymond S. <dst...@or...> - 2001-01-11 04:53:05
|
You know what we need. A super button widget. I just noticed I have = for js calls for differing button type. The ideal button would: 1) Contain the ability to; a) be defined and colored ala HTML (button.js) b) pull in images (ala ButtonImage), but have three states: static, = mouseover and clicked c) act as a 'href clicked marker", ie.... have a chnage state per = session if it has been clicked once. d) perform as a check box (boolean toggle, imagebutton.js) e) and have the abilty to be skined and defined by multiple themes. I have all this spread across 4 differing widgets, once I integrate this = into a super hacked version of what little I know I will contribute it. Later |
|
From: Raymond S. <dst...@or...> - 2001-01-11 06:45:28
|
It's a question. Pushpanel, scrollpane all extend viewport, which you can feed a Label = into. Is it possible to feed content into a loadpanel within a scrollpane, = pushpanel extended viewport? |
|
From: Raymond S. <dst...@or...> - 2001-01-11 06:59:17
|
Never mind, figured it out. It helps to post these questions here... = the shear pressure of knowing you guess are wondering wtf I am up too = leads me to resolve it. |
|
From: Raides J. <ra...@te...> - 2001-01-11 13:02:18
|
> Raymond Smith wrote: > > You know what we need. A super button widget. I just noticed I have for js > calls for differing button type. The ideal button would: > > 1) Contain the ability to; > a) be defined and colored ala HTML (button.js) > b) pull in images (ala ButtonImage), but have three states: static, mouseover > and clicked > c) act as a 'href clicked marker", ie.... have a chnage state per session if > it has been clicked once. > d) perform as a check box (boolean toggle, imagebutton.js) > e) and have the abilty to be skined and defined by multiple themes. > > I have all this spread across 4 differing widgets, once I integrate this into > a super hacked version of what little I know I will contribute it. > > Later It's not just that, but I have two .js that I can send you under request (different versions available, so you have to ask which one you choose) that implement what I call an "active area", i.e. a region in web-page space which responds to mouse events and generates its own event calls, and what I call an "icon", which is a 4-state imagebutton (all 4 images can be the same). The "Icono" (the name of the object icon) object has methods to activate it (state=0), deactivate it (state=3) and change it's default state (0=on, 1=mouseover, 2=click, 3=off). They generate just the "onClick" event when clicked and active with a parameter which is the index of the icon in the "Area" (the active area object) they MUST be contained on to work. This way you can group them logically and assign the same method to the "onClick" event of each related group of buttons and then differentiate in code using a "switch()" statement. One interesting "side-effect" derived from the way I have implemented the "Icono" is that you can have a different image in place of the icon, and it gets replaced on the first mouse event on the icon. Other side-effect is that you can have the area and the icon responding to mouse events in one place of the page and the associated image changing state in other part ;) The "Area" object is rather different. One of the versions needs always a DynLayer 1.0 version of layer to attach itself to for the dimension information (the older version). The other two versions can be created independent of any other object or attached to DynLayers 1.0 and DynAPI DynLayers respectively. They have methods to change the size of the active area, to move the top-left corner, to activate and deactivate them, and to dump it's internal information as an "alert" method. The events fired are of a wide sort and ALL provide the mouse coordinates in RELATIVE or ABSOLUTE (page relative) vaues when the event fired. Overimposed areas fire all at the same time if they are active, so multiple areas can react to a single mouse event at once. The mouse events are: onMouseIn --> Fires just when the mouse enters the area and just once onMouseDown --> Fires on the mouse down phase of a button press (just the left button) onMouseUp --> Fires on the mouse up phase of a button press (just the left button). This only fires IF the mouse is INSIDE the area. In case it's moved outside while the mouse is down (dragging), the event fired will be the next one. onMouseOut --> Fires just once the mouse exits from the area and after an "onMouseIn" event has occurred. It can fire in the middle of an "onMouseDown"-"onMouseUp" sequence. onMouseOver --> Fires WHILE the mouse is INSIDE the area. onClick --> Fires IF the "onMouseDown" AND the "onMouseUp" events occur in sequence and INSIDE the area. If the mouse gets out of the area before the button is up, no event is fired. The usual sequence for this events is: "onMouseIn" - "onMouseOver" (more than once) - "onMouseOut" for the mouse movement events, and "onMouseDown" - "onMouseUp" - "onClick" for the button mouse events. This more than extends the standard behaviour and you can easily add an "onMouseUpOut" event to capture the button release when it started inside and ended outside of the area, so an "Area.mueveA(x,y)" with the appropiate coordinates will effectively "drag" the area (and its related DynLayer, if any) to the new mouse coordinates. They also rely on two small "all-purpose" auxiliar files: "funcaux.js" and "funcesp.js" that give some general methods to simplify code. The complete list will be posted or sent on request, but I will just mention the cross-browser compatible "BuscaImagen(nombre)" that searches for any image in any layer of the document by name, even in nested layers in NS4. Returns "null" on error and the image object on success. I hope these (and other objects I have created) will help developers get a more interactive content to their DHTML pages. Raides J. |
|
From: Richard :o <ma...@ri...> - 2001-01-11 13:41:32
|
Of course you should attache the files, is there also a working example somewhere? Cheers, Richard :o ma...@ri... www.richardinfo.com (Everything running on, and ported to the 19/12/2000 snapshot of DynAPI2) ----- Original Message ----- From: "Raides J." <ra...@te...> To: <dyn...@li...> Sent: Thursday, January 11, 2001 2:02 PM Subject: Re: [Dynapi-Dev] [Bug #128263] PathAnimation.stopAnimation() bug (& patch) > > Raymond Smith wrote: > > > > You know what we need. A super button widget. I just noticed I have for js > > calls for differing button type. The ideal button would: > > > > 1) Contain the ability to; > > a) be defined and colored ala HTML (button.js) > > b) pull in images (ala ButtonImage), but have three states: static, mouseover > > and clicked > > c) act as a 'href clicked marker", ie.... have a chnage state per session if > > it has been clicked once. > > d) perform as a check box (boolean toggle, imagebutton.js) > > e) and have the abilty to be skined and defined by multiple themes. > > > > I have all this spread across 4 differing widgets, once I integrate this into > > a super hacked version of what little I know I will contribute it. > > > > Later > > It's not just that, but I have two .js that I can send you under request > (different versions available, so you have to ask which one you choose) that > implement what I call an "active area", i.e. a region in web-page space which > responds to mouse events and generates its own event calls, and what I call an > "icon", which is a 4-state imagebutton (all 4 images can be the same). > The "Icono" (the name of the object icon) object has methods to activate it > (state=0), deactivate it (state=3) and change it's default state (0=on, > 1=mouseover, 2=click, 3=off). They generate just the "onClick" event when > clicked and active with a parameter which is the index of the icon in the "Area" > (the active area object) they MUST be contained on to work. This way you can > group them logically and assign the same method to the "onClick" event of each > related group of buttons and then differentiate in code using a "switch()" > statement. One interesting "side-effect" derived from the way I have implemented > the "Icono" is that you can have a different image in place of the icon, and it > gets replaced on the first mouse event on the icon. Other side-effect is that > you can have the area and the icon responding to mouse events in one place of > the page and the associated image changing state in other part ;) > The "Area" object is rather different. One of the versions needs always a > DynLayer 1.0 version of layer to attach itself to for the dimension information > (the older version). The other two versions can be created independent of any > other object or attached to DynLayers 1.0 and DynAPI DynLayers respectively. > They have methods to change the size of the active area, to move the top-left > corner, to activate and deactivate them, and to dump it's internal information > as an "alert" method. The events fired are of a wide sort and ALL provide the > mouse coordinates in RELATIVE or ABSOLUTE (page relative) vaues when the event > fired. Overimposed areas fire all at the same time if they are active, so > multiple areas can react to a single mouse event at once. The mouse events are: > onMouseIn --> Fires just when the mouse enters the area and just once > onMouseDown --> Fires on the mouse down phase of a button press (just the left > button) > onMouseUp --> Fires on the mouse up phase of a button press (just the left > button). This only fires IF the mouse is INSIDE the area. In case it's moved > outside while the mouse is down (dragging), the event fired will be the next > one. > onMouseOut --> Fires just once the mouse exits from the area and after an > "onMouseIn" event has occurred. It can fire in the middle of an > "onMouseDown"-"onMouseUp" sequence. > onMouseOver --> Fires WHILE the mouse is INSIDE the area. > onClick --> Fires IF the "onMouseDown" AND the "onMouseUp" events occur in > sequence and INSIDE the area. If the mouse gets out of the area before the > button is up, no event is fired. > > The usual sequence for this events is: "onMouseIn" - "onMouseOver" (more than > once) - "onMouseOut" for the mouse movement events, and "onMouseDown" - > "onMouseUp" - "onClick" for the button mouse events. This more than extends the > standard behaviour and you can easily add an "onMouseUpOut" event to capture the > button release when it started inside and ended outside of the area, so an > "Area.mueveA(x,y)" with the appropiate coordinates will effectively "drag" the > area (and its related DynLayer, if any) to the new mouse coordinates. > > They also rely on two small "all-purpose" auxiliar files: "funcaux.js" and > "funcesp.js" that give some general methods to simplify code. The complete list > will be posted or sent on request, but I will just mention the cross-browser > compatible "BuscaImagen(nombre)" that searches for any image in any layer of the > document by name, even in nested layers in NS4. Returns "null" on error and the > image object on success. > > I hope these (and other objects I have created) will help developers get a more > interactive content to their DHTML pages. > > Raides J. > > _______________________________________________ > 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: Raymond S. <dst...@or...> - 2001-01-11 13:46:21
|
Richards our "codewhore", never ask.... just deliver! Just kidding. Night all Ray ----- Original Message ----- From: "Richard :o" <ma...@ri...> To: <dyn...@li...> Sent: Thursday, January 11, 2001 5:42 AM Subject: Re: [Dynapi-Dev] [Bug #128263] PathAnimation.stopAnimation() bug (& patch) > Of course you should attache the files, is there also a working example > somewhere? > > Cheers, > Richard :o > > ma...@ri... > www.richardinfo.com > (Everything running on, and ported to the 19/12/2000 snapshot of DynAPI2) > > ----- Original Message ----- > From: "Raides J." <ra...@te...> > To: <dyn...@li...> > Sent: Thursday, January 11, 2001 2:02 PM > Subject: Re: [Dynapi-Dev] [Bug #128263] PathAnimation.stopAnimation() bug (& > patch) > > > > > Raymond Smith wrote: > > > > > > You know what we need. A super button widget. I just noticed I have > for js > > > calls for differing button type. The ideal button would: > > > > > > 1) Contain the ability to; > > > a) be defined and colored ala HTML (button.js) > > > b) pull in images (ala ButtonImage), but have three states: static, > mouseover > > > and clicked > > > c) act as a 'href clicked marker", ie.... have a chnage state per > session if > > > it has been clicked once. > > > d) perform as a check box (boolean toggle, imagebutton.js) > > > e) and have the abilty to be skined and defined by multiple themes. > > > > > > I have all this spread across 4 differing widgets, once I integrate this > into > > > a super hacked version of what little I know I will contribute it. > > > > > > Later > > > > It's not just that, but I have two .js that I can send you under request > > (different versions available, so you have to ask which one you choose) > that > > implement what I call an "active area", i.e. a region in web-page space > which > > responds to mouse events and generates its own event calls, and what I > call an > > "icon", which is a 4-state imagebutton (all 4 images can be the same). > > The "Icono" (the name of the object icon) object has methods to activate > it > > (state=0), deactivate it (state=3) and change it's default state (0=on, > > 1=mouseover, 2=click, 3=off). They generate just the "onClick" event when > > clicked and active with a parameter which is the index of the icon in the > "Area" > > (the active area object) they MUST be contained on to work. This way you > can > > group them logically and assign the same method to the "onClick" event of > each > > related group of buttons and then differentiate in code using a "switch()" > > statement. One interesting "side-effect" derived from the way I have > implemented > > the "Icono" is that you can have a different image in place of the icon, > and it > > gets replaced on the first mouse event on the icon. Other side-effect is > that > > you can have the area and the icon responding to mouse events in one place > of > > the page and the associated image changing state in other part ;) > > The "Area" object is rather different. One of the versions needs always a > > DynLayer 1.0 version of layer to attach itself to for the dimension > information > > (the older version). The other two versions can be created independent of > any > > other object or attached to DynLayers 1.0 and DynAPI DynLayers > respectively. > > They have methods to change the size of the active area, to move the > top-left > > corner, to activate and deactivate them, and to dump it's internal > information > > as an "alert" method. The events fired are of a wide sort and ALL provide > the > > mouse coordinates in RELATIVE or ABSOLUTE (page relative) vaues when the > event > > fired. Overimposed areas fire all at the same time if they are active, so > > multiple areas can react to a single mouse event at once. The mouse events > are: > > onMouseIn --> Fires just when the mouse enters the area and just once > > onMouseDown --> Fires on the mouse down phase of a button press (just the > left > > button) > > onMouseUp --> Fires on the mouse up phase of a button press (just the left > > button). This only fires IF the mouse is INSIDE the area. In case it's > moved > > outside while the mouse is down (dragging), the event fired will be the > next > > one. > > onMouseOut --> Fires just once the mouse exits from the area and after an > > "onMouseIn" event has occurred. It can fire in the middle of an > > "onMouseDown"-"onMouseUp" sequence. > > onMouseOver --> Fires WHILE the mouse is INSIDE the area. > > onClick --> Fires IF the "onMouseDown" AND the "onMouseUp" events occur in > > sequence and INSIDE the area. If the mouse gets out of the area before the > > button is up, no event is fired. > > > > The usual sequence for this events is: "onMouseIn" - "onMouseOver" (more > than > > once) - "onMouseOut" for the mouse movement events, and "onMouseDown" - > > "onMouseUp" - "onClick" for the button mouse events. This more than > extends the > > standard behaviour and you can easily add an "onMouseUpOut" event to > capture the > > button release when it started inside and ended outside of the area, so an > > "Area.mueveA(x,y)" with the appropiate coordinates will effectively "drag" > the > > area (and its related DynLayer, if any) to the new mouse coordinates. > > > > They also rely on two small "all-purpose" auxiliar files: "funcaux.js" and > > "funcesp.js" that give some general methods to simplify code. The complete > list > > will be posted or sent on request, but I will just mention the > cross-browser > > compatible "BuscaImagen(nombre)" that searches for any image in any layer > of the > > document by name, even in nested layers in NS4. Returns "null" on error > and the > > image object on success. > > > > I hope these (and other objects I have created) will help developers get a > more > > interactive content to their DHTML pages. > > > > Raides J. > > > > _______________________________________________ > > 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 > > > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev > |
×
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