dynapi-dev Mailing List for DynAPI (Page 272)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

 http://www.opera.com/download/

	It is free (with banner)
    For Linux/win
    And suports CSS1,2 , JS1.3 , etc....

		New browser for DynApi? :)

			Malx

I've posted all my updates to CVS.  I think touched every file.

The significant changes were:

- inline creation system for Netscape now worked directly into DynLayer
- DynImage auto-resizing, this effected everything that was using DynImage
- some changes to how the "precreate", "create", and "resize" events are handled

The events took a while to work out.  I didn't like how it was setup before because it wasn't quite right when dealing with the new create system.
"precreate" should be used in widgets for doing most of the final layout for a widget as well as setting images for the layers.  Most of that stuff used to be in the "create" event, but now with the inline creation it's more effecient to do it in "precreate" because when you set the size/location/images of the layers you won't be working with true DIV elements rather with just the JS objects.  The goal is to do as little work with div's as possible before you create, so that by the time DynLayer creates the layers it already knows the size and content of them.

You still need the "create" event to check for content size, and that sort of stuff.

I had to remove all the checks for this.created from within the DynLayer and replace them with checks for this.css!=null.  The "this.created" flag is now true once the layer/div element is created, and final position/size has been set, AND all it's children are created also.  Peviously this.created was set to true before the children were created which conflicts with the way the inline creation system is supposed to work.  I updated all the widgets to make sure everything was working ok with this change.

I made a few DynLayer methods into simple functions, create() assignElement, flagChildren etc.  These don't have to be methods because they are never used manually.

Also you now have to include browser.js BEFORE dynlayer.js because in dynlayer I'm doing a check for Netscape/IE.  I updated the dynapi include list for this, but if you have any pages that don't do include('dynapi.api.*') you will have to change the order yourself.

DynImage.getImage() can be used before onLoad, the reason there was a problem in IE is you need a break point between the include()'s and the rest of the page.  I updated all the examples so they look like this:

rest of code....

</script>

Some other minor changes I can remember is the setSize/Width/Height, I made setSize call setWidth and setHeight, and in those I rearranged a few things.  I removed all references to getComponent() cause it's not needed anymore.  And DynImage.getImage won't return an Image object with .w and .h tacked on, it's unecessary - if you have any code that uses the .w and .h, just replace it with .width and .height.

What is no longer working:
- inline.js, I think something was wrong in IE
- List - Scott A, sorry I didn't get around to fixing this one, I checked it out in IE before all my changes and worked fantastic, I'd like to get it working again.  Probably just needs some precreate/create changes.  I broke it, so I'll fix it unless you want to take a stab at it.

Major bugs we should fix before a stable release:
- Loadpanel isn't working in IE4.
- Label/button setSelectable still isn't working, anyone know what changes are needed?
- Inline creation system for IE - I could do this eventually but I want to work on some other things first so if anyone else wants to give it a shot you're welcome, it should be fairly easy now that the NS code has been finalized.

Dan

Crash problems have pretty much all been solved with the change to inline creation, for a test try including /ext/inlinecreation.js in your page, you should notice a speed increase as well as much improved stability for Netscape.  I will be releasing a further improved version of DynLayer with this built in.

Dan

On Wed, Dec 13, 2000 at 04:42:24PM -0800, Doug Melvin wrote:
> I am using a label object to do highlighting of selected 
> nodes in NS.
> I am also using the scroll widget.
> 
> in the last hour I have gotten 10 fatal error message.
> Some occur in Netscape.exe, other occur in 
> netscapes js<whatever>.dll
> .These did not occur before I put the label in.
> Has anyone else experienced these problems?
> 
> This is something that needs to be addressed NOW 
> or DynAPI could die  a sudden death.
> 
> Doug Melvin

I am using a label object to do highlighting of selected=20
nodes in NS.
I am also using the scroll widget.

in the last hour I have gotten 10 fatal error message.
Some occur in Netscape.exe, other occur in=20
netscapes js<whatever>.dll
.These did not occur before I put the label in.
Has anyone else experienced these problems?

This is something that needs to be addressed NOW=20
or DynAPI could die  a sudden death.

Doug Melvin

That change won't be needed, it works slightly differently now, and for all I can tell it works perfeclty in Netcape.

Dan

On Wed, Dec 13, 2000 at 07:26:34PM +0100, Josep Monés i Teixidor wrote:
> Hi Dan!
> 
> I posted yesterday that I had a problem changing the images from a widget
> after a resize in NS4. I've noticed that DynImage has the same problem. But
> the way dynimage is made, makes it very easy to solve this problem. I've
> simply changed:
> 
>  if (!this.created || bRedraw) {
>   this.setHTML('<img name="'+this.id+'Image" src="'+imgObject.src+'"
> width='+this.w+' height='+this.h+' border=0>');
>  }
> 
> to:
>  if (!this.created || bRedraw || is.ns4) {
>   this.setHTML('<img name="'+this.id+'Image" src="'+imgObject.src+'"
> width='+this.w+' height='+this.h+' border=0>');
>  }
> 
> in setImage
> 
> You can see the original dynimage here:
> http://llibertat.com/ateneu24/fires2000/prova.html
> 
> and the modified one here:
> http://llibertat.com/ateneu24/fires2000/prova2.html
> 
> 
> I'd like it could be possible to solve this problem without redrawing. I've
> tried to redraw the tag changing the name value after each resize. And it
> seems to work, but NS 4.7 always crashes in a short time.
> 
> 
> The timer stuff?
> To periodically check if the images are loaded and invoke the handlers.
> 
> Best regards,
> 
> Josep
> 
> 
> 
> 
> -----Mensaje original-----
> De: Dan Steinman <dy...@fu...>
> Para: dyn...@li... <dyn...@li...>
> Fecha: miércoles 13 de diciembre de 2000 15:49
> Asunto: Re: [Dynapi-Dev] Re: dynimage.js (gui) - update.. but still a
> problem
> 
> 
> >I have made some significant changes to DynImage and DynLayer (not in CVS
> yet), and currently I commented out the Load timers altogether, I never
> really understood what they were for.  Everything works without it, you can
> use getImage() before DynLayer.onLoad() with no troubles.
> >
> >Can someone explain why all the load timer stuff is needed?
> >
> >Dan
> >
> >On Tue, Dec 12, 2000 at 09:24:18PM -0800, b0n3z wrote:
> >> Well I seem to have found part of the problem from a previous e-mail
> below.. but there is something still strange about this. If you refresh the
> page and do not move the mouse... In IE5 on Win2k Pro the spinning E never
> seems to stop until you move your mouse - is this correct?
> >>
> >> Solve for Error in line: 10 below - but doesn't solve the page not
> finishing the load (when mouse is not moved)
> >>
> >> -----------------------------------------------
> >> Hi!
> >>
> >> I think I've found a bug in dynimage.js that shows up in NS4.7 but not in
> >> IE4 (NS6 hangs on my Win NT 4.0 :-( ).
> >>
> >> File: gui/dynapi.js
> >> File date: 20:27, 8 Dec 2000; taken from the beta .zip in SourceForge
> >> yesterday.
> >> Line: 100
> >> was: DynImage.timerId=setTimeout(DynImage+'.loadercheck()',25);
> >> should be: DynImage.timerId=setTimeout('DynImage.loadercheck()',25);
> >>
> >> Best regards,
> >>
> >> Josep
> >>
> >> ----- Original Message -----
> >>   From: b0n3z
> >>   To: dyn...@li...
> >>   Sent: Tuesday, December 12, 2000 9:12 PM
> >>   Subject: dynimage.js (gui)
> >>
> >>
> >>   Using the latest snapshot build on
> http://dynapi.sourceforge.net/snapshot/  it seems that dynimage.js has a
> problem in it. Locally the example of dynapi.gui.dynimage.html seems to work
> fine.. but when on a site.. it has a problem. Hit the refresh button if the
> error doesn't show up the first time. Here is an example
> http://www.gotapex.com/b0n3z/beta/dynimage.html
> >>
> >>   Line: 10
> >>   Char: 2
> >>   Error: Syntax error
> >>   Code: 0
> >>
> >>   Thanks goes out to all the Gurus that Eat, Live, Sleep and Breath this
> stuff...
> >>
> >>   Ken (aka b0n3z)
> >>
> >_______________________________________________
> >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

> Why do we still use deleteFromArray ?

deleteFromArray is still useful for removing items from ordinal
(non-associative) arrays while maintaining the correct array length.

-- 
scott andrew lepera
-----------------------------------
web stuff:     www.scottandrew.com
music stuff:   www.walkingbirds.com

Why do we still use deleteFromArray ?

can't we just use the delete array[element] syntax as used a few releases
ago by Scott?

wouldn't  delete ..   be faster then cycling thru all array elements?

Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net

Hi Dan!

I posted yesterday that I had a problem changing the images from a widget
after a resize in NS4. I've noticed that DynImage has the same problem. But
the way dynimage is made, makes it very easy to solve this problem. I've
simply changed:

 if (!this.created || bRedraw) {
  this.setHTML('<img name="'+this.id+'Image" src="'+imgObject.src+'"
width='+this.w+' height='+this.h+' border=0>');
 }

to:
 if (!this.created || bRedraw || is.ns4) {
  this.setHTML('<img name="'+this.id+'Image" src="'+imgObject.src+'"
width='+this.w+' height='+this.h+' border=0>');
 }

in setImage

You can see the original dynimage here:
http://llibertat.com/ateneu24/fires2000/prova.html

and the modified one here:
http://llibertat.com/ateneu24/fires2000/prova2.html

I'd like it could be possible to solve this problem without redrawing. I've
tried to redraw the tag changing the name value after each resize. And it
seems to work, but NS 4.7 always crashes in a short time.

The timer stuff?
To periodically check if the images are loaded and invoke the handlers.

Best regards,

Josep

-----Mensaje original-----
De: Dan Steinman <dy...@fu...>
Para: dyn...@li... <dyn...@li...>
Fecha: miércoles 13 de diciembre de 2000 15:49
Asunto: Re: [Dynapi-Dev] Re: dynimage.js (gui) - update.. but still a
problem

>I have made some significant changes to DynImage and DynLayer (not in CVS
yet), and currently I commented out the Load timers altogether, I never
really understood what they were for.  Everything works without it, you can
use getImage() before DynLayer.onLoad() with no troubles.
>
>Can someone explain why all the load timer stuff is needed?
>
>Dan
>
>On Tue, Dec 12, 2000 at 09:24:18PM -0800, b0n3z wrote:
>> Well I seem to have found part of the problem from a previous e-mail
below.. but there is something still strange about this. If you refresh the
page and do not move the mouse... In IE5 on Win2k Pro the spinning E never
seems to stop until you move your mouse - is this correct?
>>
>> Solve for Error in line: 10 below - but doesn't solve the page not
finishing the load (when mouse is not moved)
>>
>> -----------------------------------------------
>> Hi!
>>
>> I think I've found a bug in dynimage.js that shows up in NS4.7 but not in
>> IE4 (NS6 hangs on my Win NT 4.0 :-( ).
>>
>> File: gui/dynapi.js
>> File date: 20:27, 8 Dec 2000; taken from the beta .zip in SourceForge
>> yesterday.
>> Line: 100
>> was: DynImage.timerId=setTimeout(DynImage+'.loadercheck()',25);
>> should be: DynImage.timerId=setTimeout('DynImage.loadercheck()',25);
>>
>> Best regards,
>>
>> Josep
>>
>> ----- Original Message -----
>>   From: b0n3z
>>   To: dyn...@li...
>>   Sent: Tuesday, December 12, 2000 9:12 PM
>>   Subject: dynimage.js (gui)
>>
>>
>>   Using the latest snapshot build on
http://dynapi.sourceforge.net/snapshot/  it seems that dynimage.js has a
problem in it. Locally the example of dynapi.gui.dynimage.html seems to work
fine.. but when on a site.. it has a problem. Hit the refresh button if the
error doesn't show up the first time. Here is an example
http://www.gotapex.com/b0n3z/beta/dynimage.html
>>
>>   Line: 10
>>   Char: 2
>>   Error: Syntax error
>>   Code: 0
>>
>>   Thanks goes out to all the Gurus that Eat, Live, Sleep and Breath this
stuff...
>>
>>   Ken (aka b0n3z)
>>
>_______________________________________________
>Dynapi-Dev mailing list
>Dyn...@li...
>http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

the loader was implemented for precaching the images, this way you can show
splash screens on your page/app while images are being loaded.

Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Dan Steinman
> Verzonden: woensdag 13 december 2000 21:08
> Aan: dyn...@li...
> Onderwerp: Re: [Dynapi-Dev] Re: dynimage.js (gui) - update.. but still a
> problem
>
>
> I have made some significant changes to DynImage and DynLayer
> (not in CVS yet), and currently I commented out the Load timers
> altogether, I never really understood what they were for.
> Everything works without it, you can use getImage() before
> DynLayer.onLoad() with no troubles.
>
> Can someone explain why all the load timer stuff is needed?
>
> Dan
>
> On Tue, Dec 12, 2000 at 09:24:18PM -0800, b0n3z wrote:
> > Well I seem to have found part of the problem from a previous
> e-mail below.. but there is something still strange about this.
> If you refresh the page and do not move the mouse... In IE5 on
> Win2k Pro the spinning E never seems to stop until you move your
> mouse - is this correct?
> >
> > Solve for Error in line: 10 below - but doesn't solve the page
> not finishing the load (when mouse is not moved)
> >
> > -----------------------------------------------
> > Hi!
> >
> > I think I've found a bug in dynimage.js that shows up in NS4.7
> but not in
> > IE4 (NS6 hangs on my Win NT 4.0 :-( ).
> >
> > File: gui/dynapi.js
> > File date: 20:27, 8 Dec 2000; taken from the beta .zip in SourceForge
> > yesterday.
> > Line: 100
> > was: DynImage.timerId=setTimeout(DynImage+'.loadercheck()',25);
> > should be: DynImage.timerId=setTimeout('DynImage.loadercheck()',25);
> >
> > Best regards,
> >
> > Josep
> >
> > ----- Original Message -----
> >   From: b0n3z
> >   To: dyn...@li...
> >   Sent: Tuesday, December 12, 2000 9:12 PM
> >   Subject: dynimage.js (gui)
> >
> >
> >   Using the latest snapshot build on
> http://dynapi.sourceforge.net/snapshot/  it seems that
> dynimage.js has a problem in it. Locally the example of
> dynapi.gui.dynimage.html seems to work fine.. but when on a
> site.. it has a problem. Hit the refresh button if the error
> doesn't show up the first time. Here is an example
> http://www.gotapex.com/b0n3z/beta/dynimage.html
> >
> >   Line: 10
> >   Char: 2
> >   Error: Syntax error
> >   Code: 0
> >
> >   Thanks goes out to all the Gurus that Eat, Live, Sleep and
> Breath this stuff...
> >
> >   Ken (aka b0n3z)
> >
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>

I have made some significant changes to DynImage and DynLayer (not in CVS yet), and currently I commented out the Load timers altogether, I never really understood what they were for.  Everything works without it, you can use getImage() before DynLayer.onLoad() with no troubles.

Can someone explain why all the load timer stuff is needed?

Dan

On Tue, Dec 12, 2000 at 09:24:18PM -0800, b0n3z wrote:
> Well I seem to have found part of the problem from a previous e-mail below.. but there is something still strange about this. If you refresh the page and do not move the mouse... In IE5 on Win2k Pro the spinning E never seems to stop until you move your mouse - is this correct?
> 
> Solve for Error in line: 10 below - but doesn't solve the page not finishing the load (when mouse is not moved)
> 
> -----------------------------------------------
> Hi!
> 
> I think I've found a bug in dynimage.js that shows up in NS4.7 but not in
> IE4 (NS6 hangs on my Win NT 4.0 :-( ).
> 
> File: gui/dynapi.js
> File date: 20:27, 8 Dec 2000; taken from the beta .zip in SourceForge
> yesterday.
> Line: 100
> was: DynImage.timerId=setTimeout(DynImage+'.loadercheck()',25);
> should be: DynImage.timerId=setTimeout('DynImage.loadercheck()',25);
> 
> Best regards,
> 
> Josep
> 
> ----- Original Message ----- 
>   From: b0n3z 
>   To: dyn...@li... 
>   Sent: Tuesday, December 12, 2000 9:12 PM
>   Subject: dynimage.js (gui)
> 
> 
>   Using the latest snapshot build on http://dynapi.sourceforge.net/snapshot/  it seems that dynimage.js has a problem in it. Locally the example of dynapi.gui.dynimage.html seems to work fine.. but when on a site.. it has a problem. Hit the refresh button if the error doesn't show up the first time. Here is an example http://www.gotapex.com/b0n3z/beta/dynimage.html
> 
>   Line: 10
>   Char: 2
>   Error: Syntax error
>   Code: 0
> 
>   Thanks goes out to all the Gurus that Eat, Live, Sleep and Breath this stuff...
> 
>   Ken (aka b0n3z)
> 

hi,
Reloaded lots but it seems ok on winMe Ie5.5 & Ns4.4 PIII 500Mhz.
Cheers,
Richard :o
  ----- Original Message -----=20
  From: b0n3z=20
  To: dyn...@li...=20
  Sent: Wednesday, December 13, 2000 6:12 AM
  Subject: [Dynapi-Dev] dynimage.js (gui)

  Using the latest snapshot build on =
http://dynapi.sourceforge.net/snapshot/  it seems that dynimage.js has a =
problem in it. Locally the example of dynapi.gui.dynimage.html seems to =
work fine.. but when on a site.. it has a problem. Hit the refresh =
button if the error doesn't show up the first time. Here is an example =
http://www.gotapex.com/b0n3z/beta/dynimage.html

  Line: 10
  Char: 2
  Error: Syntax error
  Code: 0

  Thanks goes out to all the Gurus that Eat, Live, Sleep and Breath this =
stuff...

  Ken (aka b0n3z)

Well I seem to have found part of the problem from a previous e-mail =
below.. but there is something still strange about this. If you refresh =
the page and do not move the mouse... In IE5 on Win2k Pro the spinning E =
never seems to stop until you move your mouse - is this correct?

Solve for Error in line: 10 below - but doesn't solve the page not =
finishing the load (when mouse is not moved)

-----------------------------------------------
Hi!

I think I've found a bug in dynimage.js that shows up in NS4.7 but not =
in
IE4 (NS6 hangs on my Win NT 4.0 :-( ).

File: gui/dynapi.js
File date: 20:27, 8 Dec 2000; taken from the beta .zip in SourceForge
yesterday.
Line: 100
was: DynImage.timerId=3DsetTimeout(DynImage+'.loadercheck()',25);
should be: DynImage.timerId=3DsetTimeout('DynImage.loadercheck()',25);

Best regards,

Josep

----- Original Message -----=20
  From: b0n3z=20
  To: dyn...@li...=20
  Sent: Tuesday, December 12, 2000 9:12 PM
  Subject: dynimage.js (gui)

  Using the latest snapshot build on =
http://dynapi.sourceforge.net/snapshot/  it seems that dynimage.js has a =
problem in it. Locally the example of dynapi.gui.dynimage.html seems to =
work fine.. but when on a site.. it has a problem. Hit the refresh =
button if the error doesn't show up the first time. Here is an example =
http://www.gotapex.com/b0n3z/beta/dynimage.html

  Line: 10
  Char: 2
  Error: Syntax error
  Code: 0

  Thanks goes out to all the Gurus that Eat, Live, Sleep and Breath this =
stuff...

  Ken (aka b0n3z)

Using the latest snapshot build on =
http://dynapi.sourceforge.net/snapshot/  it seems that dynimage.js has a =
problem in it. Locally the example of dynapi.gui.dynimage.html seems to =
work fine.. but when on a site.. it has a problem. Hit the refresh =
button if the error doesn't show up the first time. Here is an example =
http://www.gotapex.com/b0n3z/beta/dynimage.html

Line: 10
Char: 2
Error: Syntax error
Code: 0

Thanks goes out to all the Gurus that Eat, Live, Sleep and Breath this =
stuff...

Ken (aka b0n3z)

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Brandon Myers
> Verzonden: dinsdag 12 december 2000 17:28
> Aan: dyn...@li...
> Onderwerp: RE: [Dynapi-Dev] Inheritance

> Ya can't set properties if you don't first create them... And
> specifying of
> properties is usually done in a constructor. BUT, there's no point in
> calling the superclass's constructor if you already have the values set in
> the prototype.
> Right.. so if we are trying to code any sort of inheritance, then we must
> first make sure we are doing it correctly before we make a
> monster. The API
> wasn't originally coded to do what you are doing... it was
> originally coded
> to do exactly what I suggested:  loop through the prototype
> object and copy
> each instance.. (See Dan's original DynAPI 2 release with the
> widgetinterface object)

The properties are created with prototyping not in the constructor.
Properties belong to the object and are part of the prototype. Why wasn't
the API coded that way? I know Dan's original code was using that whole
widgetinterface but as Dan pointed out a few weeks ago we both feel that
normal prototyping is good enough to do widgets.. still not sure what the
problem is with prototyping, just look at my example it's working with
multiple widgets, sub-class inheriting and events triggering correctly.

> Ok.. so he was trying to implement some sort of inheritance... it worked,
> but had a few problems that could have been worked out. So, we go with the
> built-in prototype inheritance... We must then think of a
> standard way that
> DynLayers, or ANY object that will be used as an ancestor for inheritance,
> to be defined, and instanciated, without breaking any of the
> other rules of
> inheritance, or causing any other anomolies.

Correct, we're now using the built-in (to javascript) prototyp inheriting,
would you create your own superclass methods for C++ or Delphi aswell?
That's the way the language does it, so why not use it without adding extra
code that can contain extra bugs and uses extra memory and download time?
And what rules of inheriting are we breaking? (what rules are there!?)

> We seem to be focused in
> fitting this well rounded API into an oval inheritance hole. (Prototype
> inheritance isn't a well rounded method of inheritance). It just won't fit
> in it's current state. So... if people still want to use
> inheritance why not
> just take a few steps back, and take a good look at how the API is put
> together and integrated with the other parts. Then spin an
> altered structure
> which allows simple, stable inheritance without memory leaks, or
> anomolies.

The API is not put into an inheriting model, the widgets/UI components are.
The prototyping is stable and without memory leaks and I think it should be
obvious by now that it's the most simple way of doing it.

> It's not going to get done unless someone just does it. I have my way,
> Pascal has his, and you guys have yours.

> > This also means that the oncreate eventlistener is not correct,
> I think we
> > should restate the oncreate method of an object, because that
> > makes it work correctly in multy-chain inheriting.
> All inheritance should be done BEFORE any instances are created.. if we do
> the inheritance each time an instance is created.. there would be a
> performance hit. Why not get that over with at the begining. Or not do
> inheritance at all.

I totally agree, something that is done in prototyping seeing that the
prototyp of the object is inheriting from the object BEFORE the instance is
created.. it just sets the object's prototype chain once the file is read..

The only thing we should remember is that you just can't do creation code
inside the constructor because Javascript handles an object just like a
function, it parses and executes the code everytime it's called.. that's the
way Javascript works.

I guess will never agree on this one ;)

Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net

At 2000-12-12 14:01 , you wrote:
>> For example the ListItem class:
>> 
>>         function ListItem(text,value)
>>         {
>>             this.superClass = Label;
>>             this.superClass(text);
>>             this.value = value;
>>             ...
>>         }
>>         ListItem.prototype = new Label();
>> 
>> Perfect, except for the fact that one object is wasted to set the 
>> prototype.
>
>There's always the option of leaving out the last line if the extra
>object is a problem.

For me it's no problem, as long as I keep in mind the implications of it.

>It would only mean that if you made changes to Label.prototype at
>runtime, it wouldn't affect ListItem.prototype
>
>That could either be a good thing or a bad thing, depending what
>you want.

For me personally this would be a very bad thing...
I depend on the classes be subclassable to extend the functionality, among
other things.

>I'm not sure what the problem with the extra objects is, but you
>could make your extra objects identifiable by setting the ID:
>
>	ListItem.prototype = new Label('protoListItem');
>
>SD

The whole point I was trying to make is that the prototype is A Good Thing
(well...) and using object creators as constructors make the JavaScript
language in this way even more object-oriented.

It's true there is a (small) performance penalty but the added
functionality is well worth it in my opinion.

The biggest drawback IMHO with JS for now is the lack of
private/public/protected properties and methods. Instance variables can be
kludged however.
Even though the next revision of the language will have classes (finally!)
they can't be used in cross-browser environments.

/Lunna

> -----Original Message-----
> From: Pascal Bestebroer
> Sent: Tuesday, December 12, 2000 3:01 AM
> To: dyn...@li...
> Subject: RE: [Dynapi-Dev] Inheritance
>
>
> The whole prototype code is THE way that Javascript does inheriting (read
> the Netscape references) The problem we are facing is something we did our
> selves, in the constructor we should only SET the properties, not create
> properties or methods, that causes problems.
>
Ya can't set properties if you don't first create them... And specifying of
properties is usually done in a constructor. BUT, there's no point in
calling the superclass's constructor if you already have the values set in
the prototype.
Right.. so if we are trying to code any sort of inheritance, then we must
first make sure we are doing it correctly before we make a monster. The API
wasn't originally coded to do what you are doing... it was originally coded
to do exactly what I suggested:  loop through the prototype object and copy
each instance.. (See Dan's original DynAPI 2 release with the
widgetinterface object)

Ok.. so he was trying to implement some sort of inheritance... it worked,
but had a few problems that could have been worked out. So, we go with the
built-in prototype inheritance... We must then think of a standard way that
DynLayers, or ANY object that will be used as an ancestor for inheritance,
to be defined, and instanciated, without breaking any of the other rules of
inheritance, or causing any other anomolies. We seem to be focused in
fitting this well rounded API into an oval inheritance hole. (Prototype
inheritance isn't a well rounded method of inheritance). It just won't fit
in it's current state. So... if people still want to use inheritance why not
just take a few steps back, and take a good look at how the API is put
together and integrated with the other parts. Then spin an altered structure
which allows simple, stable inheritance without memory leaks, or anomolies.

It's not going to get done unless someone just does it. I have my way,
Pascal has his, and you guys have yours.

> This also means that the oncreate eventlistener is not correct, I think we
> should restate the oncreate method of an object, because that
> makes it work correctly in multy-chain inheriting.

All inheritance should be done BEFORE any instances are created.. if we do
the inheritance each time an instance is created.. there would be a
performance hit. Why not get that over with at the begining. Or not do
inheritance at all.

>See my latest preview release of
> dynacore, the image button inherites from the button which
> inherits from the
> dynLayer which inherits from the DynObject.. that's multi chain inheriting
> with events and everything working correctly.
>
> The only problem, as Robert pointed out, is the unassigned
> element with the
> wrong ID, this is the only thing I have to get out but the problem exists
> because we are creating a new array-element in the constructor.. which
> should not be done.
>
> Note that this problem only exists because we overwrite the ID value in
> later object constructors.
>
>
>
> Pascal Bestebroer
> pb...@oi...
> http://www.oibv.com
>

Yeah we can do that but instead you have to check for null, !x will return true if you try to do slideTo(0,0) therefore it wouldn't do anything.

so instead do:

if (x==null) x = this.x;
if (y==null) y = this.y;

Dan

On Mon, Dec 11, 2000 at 05:16:26AM +0100, Richard :o wrote:
> hi,
> In attached example the slideTo and slideBy used to run if one parameter is set to null
> can this be included in the new version again? ie:    if (!x) x = this.x;
> 
> in the same attachement the slideTo function calls itself in it's own event listener, this no longer works, 
> is this by design or error?
> 
> Cheers,
> Richard :)

I was biten by the 'no null allowed' also.
  ----- Original Message -----=20
  From: Richard :o=20
  To: dyn...@li...=20
  Sent: Sunday, December 10, 2000 8:16 PM
  Subject: [Dynapi-Dev] Possible additions to pathanim.js (Attn Dan)

  hi,
  In attached example the slideTo and slideBy used to run if one =
parameter is set to null
  can this be included in the new version again? ie:    if (!x) x =3D =
this.x;

  in the same attachement the slideTo function calls itself in it's own =
event listener, this no longer works,=20
  is this by design or error?

  Cheers,
  Richard :)

to my knowledge, and I'm almost completely positive, there is absolutely no
way to force the garbage collector to make his rounds, but it's probably
pretty efficient. They didn't want us to have to do this, so, they took away
the chance for us to clean up our own memory.

> For example the ListItem class:
> 
>         function ListItem(text,value)
>         {
>             this.superClass = Label;
>             this.superClass(text);
>             this.value = value;
>             ...
>         }
>         ListItem.prototype = new Label();
> 
> Perfect, except for the fact that one object is wasted to set the 
> prototype.

There's always the option of leaving out the last line if the extra
object is a problem.

It would only mean that if you made changes to Label.prototype at
runtime, it wouldn't affect ListItem.prototype

That could either be a good thing or a bad thing, depending what
you want.

I'm not sure what the problem with the extra objects is, but you
could make your extra objects identifiable by setting the ID:

	ListItem.prototype = new Label('protoListItem');

SD

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#FFFFFF">
<nobr>Robert Rainwater</nobr> wrote:
<blockquote TYPE=CITE>
<div WRAP>It might be better to run the timer until you have successfully<br>
created x number of layers, using their oncreate event.</div>
</blockquote>
There is no timer involved.&nbsp; It uses two date objects and compares
the times.
<p>The Stop value is not created until everything (layers and all) have
been created.
<br>It is quite noticable when using some of the more layer intensive widgets.
<p>If you wanted to, you might alter the layer code to create a count and
diskplay a message like:
<br>&nbsp;&nbsp;&nbsp; "created X layers in Y seconds"
<p>I just wanted a way of doing it for all library sets without having
to change each of the packages myself.
<br>It may be possible to use the DynObject._nullCount in Pascal's code
because most of the objects increment this when they are created.
<br>--
<br>Michael Pemberton
<br>mp...@ph...
<br>ICQ: 12107010
<br>&nbsp;
</body>
</html>

The whole prototype code is THE way that Javascript does inheriting (read
the Netscape references) The problem we are facing is something we did our
selves, in the constructor we should only SET the properties, not create
properties or methods, that causes problems.

This also means that the oncreate eventlistener is not correct, I think we
should restate the oncreate method of an object, because that makes it work
correctly in multy-chain inheriting. See my latest preview release of
dynacore, the image button inherites from the button which inherits from the
dynLayer which inherits from the DynObject.. that's multi chain inheriting
with events and everything working correctly.

The only problem, as Robert pointed out, is the unassigned element with the
wrong ID, this is the only thing I have to get out but the problem exists
because we are creating a new array-element in the constructor.. which
should not be done.

Note that this problem only exists because we overwrite the ID value in
later object constructors.

Pascal Bestebroer
pb...@oi...
http://www.oibv.com

-----Oorspronkelijk bericht-----
Van: dyn...@li...
[mailto:dyn...@li...]Namens Scott Andrew
LePera
Verzonden: dinsdag 12 december 2000 8:49
Aan: dyn...@li...
Onderwerp: Re: [Dynapi-Dev] Inheritance

On the face of it I don't think it's entirely necessary unless your goal is
to create a large hierarchy of objects, in which case you could just use the
SuperClass object as your base object and subclass everything from there.

The WidgetX model will create an extra instance of the DynLayer class in the
DynLayer unassigned[] collection, for every constructor that uses
"WidgetName.prototype = new DynLayer();" to fake inheritance.  But that
shouldn't break anything, just as long as unassigned[] remains private and
you don't loop through it for anything.

------
scott andrew lepera
sc...@sc...
web stuff: www.scottandrew.com
music stuff: www.walkingbirds.com

-----Original Message-----
From: Brandon Myers <bnd...@ho...>
To: dyn...@li... <dyn...@li...>
Date: Monday, December 11, 2000 6:14 PM
Subject: RE: [Dynapi-Dev] Inheritance

>>> Wouldn't it be better to say:
>>> MyObject.prototype = DynObject.prototype
>
>>I guess this would only create a pointer, so that changes to
>>MyObject.prototype would affect DynObject.prototype
>
>Very good point.. so should we then loop through the prototypes?..
>Assigning the individual functions, but not the entire prototype?
>Do this to avoid setting variables or objects which would then be shared by
>all instances of the subclass.
>
>function Label() {
> this.theLayer=new DynLayer();
>}
>
>Label.prototype=new DynObject();
>
>Then.....
>
>function Button() {
> this.theLayer.addEventListner(Button.mouseEvents);
>// More stuff here too.
>}
>Button.mouseEvents=...blah blah blah....
>Button.prototype=new Label(); // Cause a button is just a label with
events.
>
>Now.. guess what? All instances of Button will share the same DynLayer
>reference.
>Is this what is intended? I don't think so.
>
>Now.. don't get on my case that I used Dan's original widget model.. it's
>just a practical example. Any object in place of the "theLayer" object
would
>have the same problems.
>
>-----Original Message-----
>From: dyn...@li...
>[mailto:dyn...@li...]On Behalf Of Simon Dicon
>Montford
>Sent: Monday, December 11, 2000 6:12 PM
>To: dyn...@li...
>Subject: RE: [Dynapi-Dev] Inheritance
>
>
>> I was wondering the point of this line when inheriting objects:
>>
>> MyObject.prototype = new DynObject();
>
>It's so that any changes to DynObject.prototype at runtime will
>be reflected in MyObject.prototype
>
>> Wouldn't it be better to say:
>> MyObject.prototype = DynObject.prototype
>
>I guess this would only create a pointer, so that changes to
>MyObject.prototype would affect DynObject.prototype
>
>SD
>_______________________________________________
>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

Then when does it run, and is it able to be controlled... ie: can we force
it to run, such as in several other common languages?

-----Original Message-----
From: dyn...@li...
[mailto:dyn...@li...]On Behalf Of Jared
Nuzzolillo
Sent: Monday, December 11, 2000 10:00 AM
To: dyn...@li...
Subject: Re: [Dynapi-Dev] core api -- DynLayer Questions

per page memory management was abandoned, as far as I know, in Netscape
version 2.0. IE3+ and NS4+ use a variation of the mark and sweep garbage
collection algorithm.

_______________________________________________
Dynapi-Dev mailing list
Dyn...@li...
http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

It might be better to run the timer until you have successfully
created x number of layers, using their oncreate event.

-- 
// Robert Rainwater

On 12/11/2000, 11:44:23 PM EST, Michael wrote about "[Dynapi-Dev] Speed test":

> With all the talk of splitting the API and attempting to make it smaller
> / faster, I thought it would be useful to be able to see how long it
> actually take a page to download / render without the use of a stop
> watch.

> Here's what I did:

> I added the following line before "DynAPI = {"
>     var Start = new Date()

> I also added the following lines at the end of the loadhandler function:

>   var Stop = new Date();
>   var Diff = (Stop.getTime() - Start.getTime()) / 1000;
>   window.status='Page loaded in: ' + Diff + ' seconds';

> I hope this is of some use.
> --
> Michael Pemberton
> mp...@ph...
> ICQ: 12107010

With all the talk of splitting the API and attempting to make it smaller
/ faster, I thought it would be useful to be able to see how long it
actually take a page to download / render without the use of a stop
watch.

Here's what I did:

I added the following line before "DynAPI = {"
    var Start = new Date()

I also added the following lines at the end of the loadhandler function:

  var Stop = new Date();
  var Diff = (Stop.getTime() - Start.getTime()) / 1000;
  window.status='Page loaded in: ' + Diff + ' seconds';

I hope this is of some use.
--
Michael Pemberton
mp...@ph...
ICQ: 12107010

2000	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (75)	Nov (252)	Dec (418)
2001	Jan (659)	Feb (1039)	Mar (870)	Apr (235)	May (329)	Jun (251)	Jul (123)	Aug (119)	Sep (67)	Oct (194)	Nov (535)	Dec (133)
2002	Jan (122)	Feb (24)	Mar (29)	Apr (28)	May (16)	Jun (20)	Jul (11)	Aug (12)	Sep (13)	Oct (14)	Nov (23)	Dec (19)
2003	Jan (28)	Feb (170)	Mar (288)	Apr (211)	May (126)	Jun (166)	Jul (131)	Aug (102)	Sep (211)	Oct (301)	Nov (22)	Dec (6)
2004	Jan (14)	Feb (16)	Mar (7)	Apr	May (8)	Jun (25)	Jul (21)	Aug (2)	Sep (7)	Oct	Nov (2)	Dec (1)
2005	Jan (4)	Feb (2)	Mar (14)	Apr (24)	May (3)	Jun (7)	Jul (30)	Aug (5)	Sep (1)	Oct (3)	Nov	Dec (1)
2006	Jan	Feb	Mar	Apr (1)	May	Jun	Jul	Aug	Sep (4)	Oct	Nov	Dec

dynapi-dev Mailing List for DynAPI (Page 272)

dynapi-dev — List related to the current DynAPI Core development