Put we then have too many different events being triggered for basically the
same action.
Just look at the way that browsers deal with events such as the mouse ones.
They just trigger the same event and give it a property to distinguish
between the possibilities.
>From: Robert Rainwater <[EM
On 11/25/2001, Colin Thompson wrote:
> Curently each animation, circle, path etc generates it's own events ie -
> circlerun, pathstart etc..
> should they all not invoke the same events? such as a onmove event.
Because if you wan't to use two different animations (wipe, slide) on
the same layer,
I propose that we use the same style object that Pascal wrote for his
DynaCore distro. This can then become a base object that each widget can
extend if needs be.
I have a version on my website that I use for the themes.
To this end, I suggest that we add a setTheme method to as many of the
I don't have some code yet, but I will try knock some up tonight.
I am at work at the moment, but will be home in about 6 hours. I may not be
back online until after 9pm tonight (~10 hour away). I'll keep you posted.
>From: "Colin Thompson" <[EMAIL PROTECTED]>
>Your idea for an AnimEvent sou
Yes, that is exactly what I had in mind, much more efficient. Does anyone
else consider Michael's code as a possible enhancement for what we currently
have?
As it stands the animation system we have never really seems to have got
finished. As an example of elegant code they work well, but for pra
Yes, I realised later about the bad choice of the onmove example, but at
least you got what I meant :)
Your idea for an AnimEvent sounds very interesting, have you developed
anything from it yet?
- Original Message -
From: "Michael Pemberton" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
S
Maybe you would like to rewrite these widgets as a TComponent based I'll
help rewrite If we can use my style.
8an
___
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://www.mail-archive.com/[email protected]/
It seems to me looking at the various sites out there created with DynAPI
that the first thing everyone does is rewrite the GUI components. Most of
the regular posters on the list have there own button widget or scrollbar
posted on Richard's site and they all have one thing in common. Unlike the
c
Curently each animation, circle, path etc generates it's own events ie -
circlerun, pathstart etc..
should they all not invoke the same events? such as a onmove event.
for example..
you create a layer and attach it to a path, a circle and a hover animation,
and you want to know when that layer s
I want to get your thoughts on overhauling the current animation code.
It seems to me that you have to include an awful lot of code to do something
as simple as a slide or a wipe on a layer. Looking at the way the current
animation extensions are created shows that apart from the run methods they
Would it not be more apropriate to change DynLayer.specificRemove() into
DynLayer.specificDelete(); ?
My reasoning is this, if you want to call removefromParent() on a layer it
should do just that - remove it from it's parent. But in the present code it
also get deleted.
DynLayer.specificRemove(
Testing IE 5.5 windows ME
There is a serious problem with the current viewport code. take a look at
either the viewport or scrollpane examples, you can only add each label
once. The second time you try to add a label it's width and height are
unset.
Currently when we call viewport.setContent();
Two things:
a. In current widget code there are many times when you use privates (such
as this.w) instead of the corresponding get method (this.getWidth()). I know
we are looking to save bytes everywhere but if it is a reoccurring line then
write var w = this.getWidth() and other wise you should j
Testing using IE 5.5 Windows ME
There seems to be a problem with moving empty layers around on screen either
by dragging or using the various animations.
Whenever the layer is empty, ie - just the width and height set and either a
background color or background image - nothing else - the cursor
14 matches
Mail list logo
