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

[Dynapi-Dev] Speed fix

[Pascal B. <pa...@dy...>]

I did another try to make the api faster.. It seems that the setClip()
method was the biggest slowdown, so I modified it slightly:

DynLayer.prototype.setClip=function(clip) {
	if (!this.created) {
		this.clip=clip
		return
	}
//	var cc=this.getClip()		// <- not really needed..
//	for (var i in clip) if (clip[i]==null) clip[i]=cc[i] // <- same here
	var c=this.css.clip
	if (is.ns4) {
		c.top=clip[0]||0			// <- use hard-coded default values, also in IS/NS5
line below
		c.right=clip[1]||this.w
		c.bottom=clip[2]||this.h
		c.left=clip[3]||0
	}
	else if (is.ie || is.ns5) this.css.clip="rect("+(clip[0]||0)+"px
"+(clip[1]||this.w)+"px "+(clip[2]||this.h)+"px "+(clip[3]||0)+"px)"
}

Please test and see if your code initialises a little faster (slower
machines
should have better results)

This setClip() might not be as accurate as the previous one, because I'm
skipping
the getClip() method completely, and simply use the defined width and height
values as
default (instead of any other values).. this shouldn't be a problem because
setClip
is always called with all 4 parameters specified (atleast from within the
DynAPI itself)
Which brings up the question: is there a need for default values? why not
make it so that
setClip() ALWAYS needs an array of 4 elements, saves a few other checks and
speeds things up
a bit more (talking about milli-milliseconds here :)

Let me know if nothing breakes, and if it actually makes a difference in
speed.

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

RE: [Dynapi-Dev] Benchmark code

[Pascal B. <pa...@dy...>]

hmm, maybe benchmark was not the correct name..

it's more at test-case kinda thing, to test if the DynAPI
works on all browsers ..

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


-----Oorspronkelijk bericht-----
Van: dyn...@li...
[mailto:dyn...@li...]Namens Darin Kadrioski
Verzonden: dinsdag 31 oktober 2000 20:55
Aan: 'dyn...@li...'
Onderwerp: RE: [Dynapi-Dev] Benchmark code



Perhaps we can make a global pool on someones server (i'll voulenteer if
need be)

I did something short and simple at my last job to facilitate browser
benchmarking.

they still have the page up at
http://www.mah.lason.com/benchmark.cfm

-----Original Message-----
From: Pascal Bestebroer [mailto:pa...@dy...]
Sent: Tuesday, October 31, 2000 11:00 AM
To: Dev
Subject: [Dynapi-Dev] Benchmark code


Here's the initial benchmark code I've been working on/with

Place these files in a folder called benchmark (same level as the examples/
or js/ folder)
and open the first test.

There are still some things not being tested (document events for one, and
dyndoc-frames)
but I'll add these soon.

The tests seem to work ok on IE5, IE4 and NS4.7 (and so does the DynAPI
ofcourse :-)
hopefully people can test them on other browsers/platforms.

Let me know what you think of it..

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

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

RE: [Dynapi-Dev] Benchmark code

[Darin K. <dka...@ef...>]

Perhaps we can make a global pool on someones server (i'll voulenteer if
need be)

I did something short and simple at my last job to facilitate browser
benchmarking.

they still have the page up at
http://www.mah.lason.com/benchmark.cfm

-----Original Message-----
From: Pascal Bestebroer [mailto:pa...@dy...]
Sent: Tuesday, October 31, 2000 11:00 AM
To: Dev
Subject: [Dynapi-Dev] Benchmark code


Here's the initial benchmark code I've been working on/with

Place these files in a folder called benchmark (same level as the examples/
or js/ folder)
and open the first test.

There are still some things not being tested (document events for one, and
dyndoc-frames)
but I'll add these soon.

The tests seem to work ok on IE5, IE4 and NS4.7 (and so does the DynAPI
ofcourse :-)
hopefully people can test them on other browsers/platforms.

Let me know what you think of it..

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

RE: [Dynapi-Dev] Widgets (was [no subject])

[Pascal B. <pa...@dy...>]

what exactly would be the standard constructor code? just the

this.DynLayer.. (new widgets)

and

this.id='...'

lines, right?

not sure what other code you would want in there..


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



-----Oorspronkelijk bericht-----
Van: dyn...@li...
[mailto:dyn...@li...]Namens Jordi 'IlMaestro'
Ministral
Verzonden: dinsdag 31 oktober 2000 19:25
Aan: dyn...@li...
Onderwerp: Re: [Dynapi-Dev] Widgets (was [no subject])


Yes I know but makeDynLayer could also assign the prototype

...
eval(method+".prototype = new DynLayer")
..
..

Still speaking in theory


Scott Andrew LePera wrote:

> I think what's being overlooked in your idea is that prototype methods
> won't be inherited.  makeWidget creates a string of the contents of the
> *constructor*; but it doesn't include the prototype properties.
>
> It looks like makeWidget creates an entire new constructor.  If you
> passed DynLayer to makeWidget it would return a completely new object
> identical to DynLayer constructor as your widget base, plus any
> modifications you made.  Is this a good approach?
>
> scottandrew
>
> Jordi 'IlMaestro' Ministral wrote:
> >
> > What is trying to do is, given that the toString method of a function
return its
> > source code, is to add lines just after "function() {" and before the
source, and then
> > eval the new function. So the function passed as parameter is rewriten.
> >
> > This way we can have clean widget constructors and automatically add all
the
> > initializations code that make a widget a widget. If this code is to be
changed we
> > don't have to bother editing th widget sources because that inheriting
code is added
> > by the API and not hard-coded into each constructor.
> >
> > The idea is turn method to string, split into to strings: until { and
after }, insert
> > our code between them and eval everything.
> >
> > Robert Rainwater wrote:
> >
> > > I'm not quite sure I follow your DynAPI.makeWidget.  Could you explain
> > > that in a little more detail.  I don't understand what makeWidget is
> > > trying to do there.
> > >
> > > Robert
> > >
> > > --
> > > Email: <mailto:rra...@ya...>
> > > PGP Key ID: 0x703D7F7C
> > >
> > > > I've been thinking about this for some tome now and our main problem
here is
> > > > having all our widgets to share the DynLayer functionalities without
sharing any
> > > > properties. We need some sort of initialization code such as:
> > > >
> > > > myWidget = function() {
> > > >     // Init code
> > > >
> > > >     // Assign id
> > > >     this.id = ...
> > > >
> > > >     // Widget stuff starts here
> > > >
> > > > }
> > > >
> > > > // Maybe not anymore
> > > > myWidget.prototype
> > > >
> > > >
> > > > However hard-coding it into all our widgets is a pain and when we
need to change
> > > > something then we have to edit all of your widgets and we force
people to
> > > > 'remember' whet has to be placed at the beggining of each
constructor. I thing
> > > > this can be solved by having this method (this is the idea, I
haven't been able
> > > > to code it)
> > > >
> > > > DynAPI.makeWidget = function(constructor) {
> > > > var code = window[constructor].toString()
> > > > // now we have the code
> > > > var header = code.substring(0,code.indexOf("{"))
> > > > var rest = code.substring(code.indexOf("{"))
> > > > var newcode = header + have all the common init stuff in a String
here + rest
> > > > eval(constructor+" = "+newcode)
> > > >
> > > > // If needed attach prototying, assign variables, etc.
> > > > }
> > > >
> > > >
> > > > This way your widget code should be independent of the inheritance
method
> > > > adopted. This I presume, I haven't tested. Tell me what you think
> > > >
> > >
> > > _______________________________________________
> > > 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

RE: [Dynapi-Dev] Fixes n stuff

[Pascal B. <pa...@dy...>]

ermz, you have access to a Mac?


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



-----Oorspronkelijk bericht-----
Van: dyn...@li...
[mailto:dyn...@li...]Namens Robert Rainwater
Verzonden: maandag 30 oktober 2000 23:44
Aan: Pascal Bestebroer
Onderwerp: Re: [Dynapi-Dev] Fixes n stuff



In DynLayer.deleteElement() I changed:

if (is.ie5 && this.elm.children.length>0) this.elm.removeNode(true)
-to-
if (is.ie5&&is.platform=="win32"&&this.elm.children.length>0)
this.elm.removeNode(true)

It seems that the IE 5 for the Mac doesn't support that either, so I
added the windows check.

I also set the .children = [] initialialy, so no more checking for it
being an array and removed the hasChildren stuff.

I updated the release at sourceforge.

Robert

--
Email: <mailto:rra...@ya...>
PGP Key ID: 0x703D7F7C


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

[Dynapi-Dev] Benchmark code

[Pascal B. <pa...@dy...>]

Here's the initial benchmark code I've been working on/with

Place these files in a folder called benchmark (same level as the examples/
or js/ folder)
and open the first test.

There are still some things not being tested (document events for one, and
dyndoc-frames)
but I'll add these soon.

The tests seem to work ok on IE5, IE4 and NS4.7 (and so does the DynAPI
ofcourse :-)
hopefully people can test them on other browsers/platforms.

Let me know what you think of it..

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

Re: [Dynapi-Dev] Widgets (was [no subject])

[Jordi 'I. M. <jmi...@or...>]

Yes I know but makeDynLayer could also assign the prototype

...
eval(method+".prototype = new DynLayer")
..
..

Still speaking in theory


Scott Andrew LePera wrote:

> I think what's being overlooked in your idea is that prototype methods
> won't be inherited.  makeWidget creates a string of the contents of the
> *constructor*; but it doesn't include the prototype properties.
>
> It looks like makeWidget creates an entire new constructor.  If you
> passed DynLayer to makeWidget it would return a completely new object
> identical to DynLayer constructor as your widget base, plus any
> modifications you made.  Is this a good approach?
>
> scottandrew
>
> Jordi 'IlMaestro' Ministral wrote:
> >
> > What is trying to do is, given that the toString method of a function return its
> > source code, is to add lines just after "function() {" and before the source, and then
> > eval the new function. So the function passed as parameter is rewriten.
> >
> > This way we can have clean widget constructors and automatically add all the
> > initializations code that make a widget a widget. If this code is to be changed we
> > don't have to bother editing th widget sources because that inheriting code is added
> > by the API and not hard-coded into each constructor.
> >
> > The idea is turn method to string, split into to strings: until { and after }, insert
> > our code between them and eval everything.
> >
> > Robert Rainwater wrote:
> >
> > > I'm not quite sure I follow your DynAPI.makeWidget.  Could you explain
> > > that in a little more detail.  I don't understand what makeWidget is
> > > trying to do there.
> > >
> > > Robert
> > >
> > > --
> > > Email: <mailto:rra...@ya...>
> > > PGP Key ID: 0x703D7F7C
> > >
> > > > I've been thinking about this for some tome now and our main problem here is
> > > > having all our widgets to share the DynLayer functionalities without sharing any
> > > > properties. We need some sort of initialization code such as:
> > > >
> > > > myWidget = function() {
> > > >     // Init code
> > > >
> > > >     // Assign id
> > > >     this.id = ...
> > > >
> > > >     // Widget stuff starts here
> > > >
> > > > }
> > > >
> > > > // Maybe not anymore
> > > > myWidget.prototype
> > > >
> > > >
> > > > However hard-coding it into all our widgets is a pain and when we need to change
> > > > something then we have to edit all of your widgets and we force people to
> > > > 'remember' whet has to be placed at the beggining of each constructor. I thing
> > > > this can be solved by having this method (this is the idea, I haven't been able
> > > > to code it)
> > > >
> > > > DynAPI.makeWidget = function(constructor) {
> > > > var code = window[constructor].toString()
> > > > // now we have the code
> > > > var header = code.substring(0,code.indexOf("{"))
> > > > var rest = code.substring(code.indexOf("{"))
> > > > var newcode = header + have all the common init stuff in a String here + rest
> > > > eval(constructor+" = "+newcode)
> > > >
> > > > // If needed attach prototying, assign variables, etc.
> > > > }
> > > >
> > > >
> > > > This way your widget code should be independent of the inheritance method
> > > > adopted. This I presume, I haven't tested. Tell me what you think
> > > >
> > >
> > > _______________________________________________
> > > 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

Re: [Dynapi-Dev] Widgets (was [no subject])

[Scott A. L. <sc...@sc...>]

I think what's being overlooked in your idea is that prototype methods
won't be inherited.  makeWidget creates a string of the contents of the
*constructor*; but it doesn't include the prototype properties.

It looks like makeWidget creates an entire new constructor.  If you
passed DynLayer to makeWidget it would return a completely new object
identical to DynLayer constructor as your widget base, plus any
modifications you made.  Is this a good approach?

scottandrew

Jordi 'IlMaestro' Ministral wrote:
> 
> What is trying to do is, given that the toString method of a function return its
> source code, is to add lines just after "function() {" and before the source, and then
> eval the new function. So the function passed as parameter is rewriten.
> 
> This way we can have clean widget constructors and automatically add all the
> initializations code that make a widget a widget. If this code is to be changed we
> don't have to bother editing th widget sources because that inheriting code is added
> by the API and not hard-coded into each constructor.
> 
> The idea is turn method to string, split into to strings: until { and after }, insert
> our code between them and eval everything.
> 
> Robert Rainwater wrote:
> 
> > I'm not quite sure I follow your DynAPI.makeWidget.  Could you explain
> > that in a little more detail.  I don't understand what makeWidget is
> > trying to do there.
> >
> > Robert
> >
> > --
> > Email: <mailto:rra...@ya...>
> > PGP Key ID: 0x703D7F7C
> >
> > > I've been thinking about this for some tome now and our main problem here is
> > > having all our widgets to share the DynLayer functionalities without sharing any
> > > properties. We need some sort of initialization code such as:
> > >
> > > myWidget = function() {
> > >     // Init code
> > >
> > >     // Assign id
> > >     this.id = ...
> > >
> > >     // Widget stuff starts here
> > >
> > > }
> > >
> > > // Maybe not anymore
> > > myWidget.prototype
> > >
> > >
> > > However hard-coding it into all our widgets is a pain and when we need to change
> > > something then we have to edit all of your widgets and we force people to
> > > 'remember' whet has to be placed at the beggining of each constructor. I thing
> > > this can be solved by having this method (this is the idea, I haven't been able
> > > to code it)
> > >
> > > DynAPI.makeWidget = function(constructor) {
> > > var code = window[constructor].toString()
> > > // now we have the code
> > > var header = code.substring(0,code.indexOf("{"))
> > > var rest = code.substring(code.indexOf("{"))
> > > var newcode = header + have all the common init stuff in a String here + rest
> > > eval(constructor+" = "+newcode)
> > >
> > > // If needed attach prototying, assign variables, etc.
> > > }
> > >
> > >
> > > This way your widget code should be independent of the inheritance method
> > > adopted. This I presume, I haven't tested. Tell me what you think
> > >
> >
> > _______________________________________________
> > 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

Re: [Dynapi-Dev] EventMethod

[Robert R. <rra...@ya...>]

It seems the events are broken.  So, I changed the EventMethod a bit
so that it uses one method and uses some of Micheal's changes:

DynLayer.prototype.EventMethod = function(e) {
        var dyndoc=this.lyrobj.dyndoc
        if (is.ie) {
                // *** check type of object
                var e=this.lyrobj.isDynLayer? dyndoc.elm.event : this.lyrobj.elm.event
                // ***
                e.cancelBubble=true
                if (e.type=="click" && DynAPI.wasDragging && this.lyrobj.isDynLayer) {
                        e.cancelBubble=true
                        DynAPI.wasDragging=false
                        return true
                }
                if (e.type!="mouseout" && e.type!="mouseover") e.cancelBubble=true
                if (e.type=="mouseout" && this.contains(e.toElement)) return true
                if (e.type=="mouseover" && this.contains(e.fromElement)) return true
        }
        var realsrc=is.ie ? e.srcElement:e.target
        var which=(is.ie||is.ns5)?e.button:e.which
        
        // *** should set the correct source
        var src=realsrc.lyrobj||dyndoc
        if (!src) return true
        // ***
        var evt=dyndoc._e
        evt.setEvent(src,e)
        var type=evt.type
        src.invokeEvent(type,evt)
        if (e.type=="mouseover" || e.type=="mouseout") return false
        // *** send event on
        return evt.bubbleEvent()
        // ***
}

// use same dynlayer method
DynDocument.prototype.EventMethod = DynLayer.prototype.EventMethod


Robert

-- 
Email: <mailto:rra...@ya...>
PGP Key ID: 0x703D7F7C

Re: [Dynapi-Dev] Widgets (was [no subject])

[Jordi 'I. M. <jmi...@or...>]

What is trying to do is, given that the toString method of a function return its
source code, is to add lines just after "function() {" and before the source, and then
eval the new function. So the function passed as parameter is rewriten.

This way we can have clean widget constructors and automatically add all the
initializations code that make a widget a widget. If this code is to be changed we
don't have to bother editing th widget sources because that inheriting code is added
by the API and not hard-coded into each constructor.

The idea is turn method to string, split into to strings: until { and after }, insert
our code between them and eval everything.

Robert Rainwater wrote:

> I'm not quite sure I follow your DynAPI.makeWidget.  Could you explain
> that in a little more detail.  I don't understand what makeWidget is
> trying to do there.
>
> Robert
>
> --
> Email: <mailto:rra...@ya...>
> PGP Key ID: 0x703D7F7C
>
> > I've been thinking about this for some tome now and our main problem here is
> > having all our widgets to share the DynLayer functionalities without sharing any
> > properties. We need some sort of initialization code such as:
> >
> > myWidget = function() {
> >     // Init code
> >
> >     // Assign id
> >     this.id = ...
> >
> >     // Widget stuff starts here
> >
> > }
> >
> > // Maybe not anymore
> > myWidget.prototype
> >
> >
> > However hard-coding it into all our widgets is a pain and when we need to change
> > something then we have to edit all of your widgets and we force people to
> > 'remember' whet has to be placed at the beggining of each constructor. I thing
> > this can be solved by having this method (this is the idea, I haven't been able
> > to code it)
> >
> > DynAPI.makeWidget = function(constructor) {
> > var code = window[constructor].toString()
> > // now we have the code
> > var header = code.substring(0,code.indexOf("{"))
> > var rest = code.substring(code.indexOf("{"))
> > var newcode = header + have all the common init stuff in a String here + rest
> > eval(constructor+" = "+newcode)
> >
> > // If needed attach prototying, assign variables, etc.
> > }
> >
> >
> > This way your widget code should be independent of the inheritance method
> > adopted. This I presume, I haven't tested. Tell me what you think
> >
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

[Dynapi-Dev] EventMethod

[Robert R. <rra...@ya...>]

I was wondering why the DynLayer.EvenMethod and
DynDocument.EventMethod couldn't be combined since we can distinguish
between the two.

Like
DynDocument.prototype.EventMethod=DynLayer.prototype.EventMethod

I haven't tested yet, but then couldn't you say:

DynLayer.prototype.EventMethod = function(e) {
        var dyndoc=this.isDynLayer? this.lyrobj.dyndoc : this.lyrobj
        if (is.ie) {
                var e=dyndoc.elm.event
        .....
        

Robert

-- 
Email: <mailto:rra...@ya...>
PGP Key ID: 0x703D7F7C

Re: [Dynapi-Dev] include method

[Robert R. <rra...@ya...>]

Here's the patch that was posted:


// This version of DynAPI.include prevents a file from being included twice.
// This allows extension .js files to include their prerequisite
//  extension .js files with relative impunity.
// NOTE: core.api.* should be included in the html file normally.
//  DynLayer and DynDocument need to be defined properly for widgets
//  to be defined.

        include : function(src,path) { 
                if (!DynAPI.included) DynAPI.included = ''
                if (!path) path=DynAPI.librarypath
                groupname=src.substring(src.indexOf('.')+1)
                groupname=groupname.substring(0,groupname.indexOf('.'))
                var newhtml=''
                
                if (src.indexOf('.*')>0) {
                        src=src.substring(0,src.indexOf('.*'))
                        group=eval('DynAPI.'+groupname)
                        if (group) for (var i in group) {
                                if (0>DynAPI.included.indexOf(path+groupname+'/'+src+'.'+group[i])) {
                                        newhtml+='<script language="Javascript1.2" src="'+path+groupname+'/'+src+'.'+group[i]+'"><\/script>'
                                        DynAPI.included+=path+groupname+'/'+src+'.'+group[i]+'\n'
                                }
                        }
                        else alert(DynAPI.toString()+'\n\nError occured\nThe following package could not be loaded:\n'+src+'\n\nmake sure you specified the correct path.')
                } else {
                        if (0>DynAPI.included.indexOf(path+groupname+'/'+src)) {
                                newhtml+='<script language="Javascript1.2" src="'+path+groupname+'/'+src+'"><\/script>'
                                DynAPI.included+=path+groupname+'/'+src+'\n'
                        }
                }
                if (''!=newhtml) document.write(newhtml)
        }


Robert

-- 
Email: <mailto:rra...@ya...>
PGP Key ID: 0x703D7F7C

> We could just do this:
> 
> src = src.split(".").join("/")
> 
> That would transform "core.gui.widget" into "core/gui/widget"
> 
> We would have to be careful with files ending in ".js" so they aren't
> interpreted as "core/gui/widget/js"
> 
> RE duplicate includes: I have some sample scripts that include the
> utility files they need to function.  For example, a certain widget
> script would include the colorops.js, slide.js, etc. from inside itself,
> without me having to declare it in the main document.  However, if a
> script has already been included then we could save a little
> time/resources by skipping those files if requested again.
> 
> Robert Rainwater wrote:
>> 
>> > Am I the only one who hates having to name my scripts after the path to
>> > them? :-)
>> >
>> > core.gui.window.js
>> > core.ibs.scroll.js
>> > core.sa.this.js
>> > core.api.that.js
>> 
>> I've never figured out why the dynapi files were named that way.  In java
>> core.gui.window.js would mean core/gui/window.js.  That seems more
>> logical to me as well.  And since we are using a directory scheme,
>> there shouldn't be a problem with files having the same name.
>> 
>> > Also: there was a proposed patch a SourceForge that would have prevented
>> > scripts from being loaded twice, but never implemented.  Was there
>> > something wrong with this approach?
>> 
>> The fix can easily be dropped in the include method.  But, I'm still not
>> sure why its needed.  Its only a couple of lines so I guess it
>> wouldn't hurt...
>> 
>> Robert
>> 
>> _______________________________________________
>> 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

Re: [Dynapi-Dev] include method

[Scott A. L. <sc...@sc...>]

We could just do this:

src = src.split(".").join("/")

That would transform "core.gui.widget" into "core/gui/widget"

We would have to be careful with files ending in ".js" so they aren't
interpreted as "core/gui/widget/js"

RE duplicate includes: I have some sample scripts that include the
utility files they need to function.  For example, a certain widget
script would include the colorops.js, slide.js, etc. from inside itself,
without me having to declare it in the main document.  However, if a
script has already been included then we could save a little
time/resources by skipping those files if requested again.

Robert Rainwater wrote:
> 
> > Am I the only one who hates having to name my scripts after the path to
> > them? :-)
> >
> > core.gui.window.js
> > core.ibs.scroll.js
> > core.sa.this.js
> > core.api.that.js
> 
> I've never figured out why the dynapi files were named that way.  In java
> core.gui.window.js would mean core/gui/window.js.  That seems more
> logical to me as well.  And since we are using a directory scheme,
> there shouldn't be a problem with files having the same name.
> 
> > Also: there was a proposed patch a SourceForge that would have prevented
> > scripts from being loaded twice, but never implemented.  Was there
> > something wrong with this approach?
> 
> The fix can easily be dropped in the include method.  But, I'm still not
> sure why its needed.  Its only a couple of lines so I guess it
> wouldn't hurt...
> 
> Robert
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

Re: [Dynapi-Dev] Fixes n stuff

[Robert R. <rra...@ya...>]

In DynLayer.deleteElement() I changed:

if (is.ie5 && this.elm.children.length>0) this.elm.removeNode(true)
-to-
if (is.ie5&&is.platform=="win32"&&this.elm.children.length>0) this.elm.removeNode(true)

It seems that the IE 5 for the Mac doesn't support that either, so I
added the windows check.

I also set the .children = [] initialialy, so no more checking for it
being an array and removed the hasChildren stuff.

I updated the release at sourceforge.

Robert

-- 
Email: <mailto:rra...@ya...>
PGP Key ID: 0x703D7F7C

Re: [Dynapi-Dev] include method

[Robert R. <rra...@ya...>]

> Am I the only one who hates having to name my scripts after the path to
> them? :-)
> 
> core.gui.window.js
> core.ibs.scroll.js
> core.sa.this.js
> core.api.that.js

I've never figured out why the dynapi files were named that way.  In java
core.gui.window.js would mean core/gui/window.js.  That seems more
logical to me as well.  And since we are using a directory scheme,
there shouldn't be a problem with files having the same name.


> Also: there was a proposed patch a SourceForge that would have prevented
> scripts from being loaded twice, but never implemented.  Was there
> something wrong with this approach?

The fix can easily be dropped in the include method.  But, I'm still not
sure why its needed.  Its only a couple of lines so I guess it
wouldn't hurt...


Robert

[Dynapi-Dev] include method

[Scott A. L. <sc...@sc...>]

Am I the only one who hates having to name my scripts after the path to
them? :-)

core.gui.window.js
core.ibs.scroll.js
core.sa.this.js
core.api.that.js

With a little modification, include could parse out the correct script
name, so you could just name your script "window.js" instead of
"core.something.window.js"

If no one cares, I'll drop the subject...but it seems a little contrary
to the way "real" programming languages work.

Also: there was a proposed patch a SourceForge that would have prevented
scripts from being loaded twice, but never implemented.  Was there
something wrong with this approach?

scottandrew

Re: [Dynapi-Dev] Fixes n stuff

[Scott A. L. <sc...@sc...>]

I don't know how it happened, but none of those array modifications in
deleteChild were in the patch I posted to SourceForge.  Pascal is
correct that deleteChild already takes care of handling the assigned and
unassigned arrays.

The children[] array was removed because of the inheritance problem with
the WidgetX model: the children[] array was being shared.  So children
is now created when you first add children to an object.

Pascal's proposed fix to the WidgetX model (using this.superClass, see
earlier posts) should correct this, but it hasn't been accepted yet as
part of the standard model for widgets.

I played around with the proposed fix for some time yesterday, and it
seems to work:

function Widget(){
  this.superClass = DynLayer <-- defines the superClass constructor as a
method
  this.superClass() <-- invokes the superClass constructor, ensuring
that this object is a unique instance
  ...
}

Widget.prototype = new DynLayer() <--- Widget prototype is based on a
unique instance of DynLayer

If this were adopted, we could go ahead and put children[] back into the
constructor of DynLayer and DynDocument and not need the hasChildren
boolean.  this.superClass() would make sure that each Widget instance
has unique values.

I think this is a fairly straightforward compromise, and you only have
to add two short lines.  Since everyone seems to like the simplicity of
the WidgetX model, I think this is the way to go.  Of course, if there
were a way to shorten it to one line...

scottandrew



Pascal Bestebroer wrote:
> 
> Ok, here are a few possible fixes for the latest release:
> 
> in: DynLayer.prototype.removeChild()
> change this: DynLayer.unassigned[DynLayer.unAssigned.length]=child
> into this: DynLayer.unassigned[DynLayer.unassigned.length]=child
> error was: the unAssigned array is not with a capital A ;)
> 
> deleteElement contains a MAJOR bug:
> 
> DynLayer.prototype.deleteElement=function() {
>         this.created=false
> /*
>         DONT DO THE FOLLOWING!
>         It's already being done by the functions that call deleteElement, so don't
>         do it here again - major problems!
> 
>         DynAPI.removeFromArray(this.dyndoc.all,this,true)
>         delete this.dyndoc.allID[this.id]
>         DynLayer.unassigned[DynLayer.unassigned.length]=this
>         DynLayer.unassignedID[this.id]=this
> */
>         if (is.ns4) {
>                 this.elm.releaseEvents(Event.LOAD)
>                 this.elm.visibility="hide"
>         } else {
>                 this.elm.style.visibility="hidden"
>                 this.elm.innerHTML=""
>                 this.elm.outerHTML=""
> // + following line won't work on IE4, so check for IE5
>                 if (is.ie5 && this.elm.children.length>0) this.elm.removeNode(true)
>         }
>         this.elm={}
>         this.doc={}
>         this.css={}
>         this.deleteChildElements()
> }
> 
> Also the inline code is totally broken, I've got a working version
> but it depends on the children array still "alive". I don't know why
> the children[] is removed (or atleast not an array at the beginning) this
> makes coding a tricky thing (always having to check for the children array
> being an array)
> 
> the widget modifications posted a few days ago should make the children[]
> problems solved,
> so that the array can always be an array, so that checks don't have to be
> done maybe saving
> a few code-breaking situations, speed and file-sizes..
> 
> anyway, here's the correct inline code (might need a children[] fix as
> mentioned, or preferably
> restore the children array to an array) :
> 
> /*
>    Core DynAPI Distribution
>    AddOn extensions
> */
> DynAPI.findLayers=function(dyndoc,or) {
>         var divs=[]
>         or=or||dyndoc
>         if (is.ns4) divs=dyndoc.doc.layers
>         if (is.ns5) divs=dyndoc.doc.getElementsByTagName("DIV")
>         if (is.ie) divs=dyndoc.doc.all.tags("DIV")
>         for (var i=0; i<divs.length; i++) {
>                 if(DynAPI.isDirectChildOf(divs[i],dyndoc.elm)) {
>                         var id=is.ns4? divs[i].name : divs[i].id
>                         var dlyr=new DynLayer(id)
> 
>                         dlyr.parent=dyndoc
>                         dlyr.assignElement(divs[i])
>                         dlyr.dyndoc=or
> 
>                 // new line here, not sure why I did it, but it fixed a few things
>                 // for events I think.
>                         if (dyndoc.getClass()!=DynDocument) dlyr.isChild=true
> 
>                         if (or.getClass()!=DynDocument) dlyr.isChild=true
>                         else {
>                 // this part was needing some fixing for Scott's new code:
>                                 DynAPI.removeFromArray(DynLayer.unassigned, dlyr, true)
>                                 delete DynLayer.unassignedID[dlyr.id]
> 
>                                 or.all[or.all.length]=dlyr
>                                 or.all[dlyr.id]=dlyr
>                                 or.allID[dlyr.id]=dlyr
>                         }
> 
>                         dyndoc.children[dyndoc.children.length]=dlyr
> 
>                         var index=id.indexOf("Div")
>                         if (index>0) dyndoc.doc.window[id.substr(0,index)] = dyndoc.all[id]
> 
>                         if (is.ns4) {for (ict in dlyr.doc.images)
> dlyr.doc.images[ict].lyrobj=dlyr}
>                         else if (is.ns5) {for (ict in dlyr.doc.images)
> dlyr.doc.images[ict].lyrobj=dlyr.elm}
>                         else {for (ict in dlyr.elm.all.tags("img"))
> dlyr.elm.all.tags("img")[ict].lyrobj=dlyr}
> 
>                         if (dlyr.updateValues) dlyr.updateValues()
> 
>                         DynAPI.findLayers(dlyr,or)
>                 }
>         }
> }
> DynLayer.prototype.updateValues=function() {
>         if (is.ns) {
>                 this.x=parseInt(this.css.left)
>                 this.y=parseInt(this.css.top)
>                 this.w=is.ns4? this.css.clip.width : parseInt(this.css.width)
>                 this.h=is.ns4? this.css.clip.height : parseInt(this.css.height)
>                 if (is.ns4)
> this.clip=[this.css.clip.top,this.css.clip.right,this.css.clip.bottom,this.c
> ss.clip.left]
>                 this.bgColor = this.doc.bgColor!="this.doc.bgColor"?this.doc.bgColor:null
>                 this.bgImage = this.elm.background.src!=""?this.elm.background.src:null
>                 this.html = this.innerHTML = this.elm.innerHTML = ""
>         }
>         else if (is.ie) {
>                 this.x=this.elm.offsetLeft
>                 this.y=this.elm.offsetTop
>                 this.w=is.ie4? this.css.pixelWidth : this.elm.offsetWidth
>                 this.h=is.ie4? this.css.pixelHeight : this.elm.offsetHeight
>                 this.bgImage = this.css.backgroundImage
>                 this.bgColor = this.css.backgroundColor
>                 this.html = this.innerHTML = this.elm.innerHTML
>         }
>         this.z = this.css.zIndex
>         var b = this.css.visibility
>         this.visible = (b=="inherit"||b=="show"||b=="visible"||b=="")
> }
> DynAPI.getModel=function() {
>         dom='DYNAPI OBJECT MODEL:\n\n+DynAPI\n'
>         for (var i=0; i<DynAPI.documents.length; i++) {
>                 dom+='  +'+DynAPI.documents[i].toString()+'\n'
>                 for (var j=0; j<DynAPI.documents[i].all.length; j++)
> dom+='+'+DynAPI.documents[i].all[j].toString()+'\n'
>         }
>         alert(dom)
> }
> DynAPI.isDirectChildOf = function(l, parent) {
>         if(is.ns) return (l.parentLayer == parent)
>         for(var p=l.parentElement;p;p=p.parentElement)
>          if(p.tagName.toLowerCase()=='div') return p==parent
>         return !parent.tagName
> }
> 
> Some doubts about the event code in the current release, there is some code
> for the
> old rtmouseup and rtmousedown events.. don't think they are needed (at least
> not in that
> state) I've got the following solution working:
> 
> Use all of Scott's  this.button  changes, and change the handleEvent()
> method into this:
> 
> EventListener.prototype.handleEvent=function(type,e)
> 
>         if (type=='mousedown' || type=='mouseup') {
>                 if (e.button==2) type='md'+type
>                 if (e.button==3) type='rt'+type
>         }
>         if (this["on"+type]) this["on"+type](e)
> }
> 
> should do correct event bubbling, and still make different events for
> rtmouseup/rtmousedown
> and mdmouseup/mdmousedown (middle button)
> 
> that's it for now.. have fun :)
> 
> Pascal Bestebroer
> pa...@dy...
> http://www.dynamic-core.net
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

[Dynapi-Dev] Fixes n stuff

[Pascal B. <pa...@dy...>]

Ok, here are a few possible fixes for the latest release:

in: DynLayer.prototype.removeChild()
change this: DynLayer.unassigned[DynLayer.unAssigned.length]=child
into this: DynLayer.unassigned[DynLayer.unassigned.length]=child
error was: the unAssigned array is not with a capital A ;)

deleteElement contains a MAJOR bug:

DynLayer.prototype.deleteElement=function() {
	this.created=false
/*
	DONT DO THE FOLLOWING!
	It's already being done by the functions that call deleteElement, so don't
	do it here again - major problems!

	DynAPI.removeFromArray(this.dyndoc.all,this,true)
   	delete this.dyndoc.allID[this.id]
    	DynLayer.unassigned[DynLayer.unassigned.length]=this
    	DynLayer.unassignedID[this.id]=this
*/
	if (is.ns4) {
		this.elm.releaseEvents(Event.LOAD)
		this.elm.visibility="hide"
	} else {
		this.elm.style.visibility="hidden"
		this.elm.innerHTML=""
		this.elm.outerHTML=""
// + following line won't work on IE4, so check for IE5
        	if (is.ie5 && this.elm.children.length>0) this.elm.removeNode(true)
	}
	this.elm={}
	this.doc={}
	this.css={}
	this.deleteChildElements()
}



Also the inline code is totally broken, I've got a working version
but it depends on the children array still "alive". I don't know why
the children[] is removed (or atleast not an array at the beginning) this
makes coding a tricky thing (always having to check for the children array
being an array)

the widget modifications posted a few days ago should make the children[]
problems solved,
so that the array can always be an array, so that checks don't have to be
done maybe saving
a few code-breaking situations, speed and file-sizes..

anyway, here's the correct inline code (might need a children[] fix as
mentioned, or preferably
restore the children array to an array) :

/*
   Core DynAPI Distribution
   AddOn extensions
*/
DynAPI.findLayers=function(dyndoc,or) {
	var divs=[]
	or=or||dyndoc
	if (is.ns4) divs=dyndoc.doc.layers
	if (is.ns5) divs=dyndoc.doc.getElementsByTagName("DIV")
	if (is.ie) divs=dyndoc.doc.all.tags("DIV")
	for (var i=0; i<divs.length; i++) {
		if(DynAPI.isDirectChildOf(divs[i],dyndoc.elm)) {
			var id=is.ns4? divs[i].name : divs[i].id
			var dlyr=new DynLayer(id)

			dlyr.parent=dyndoc
			dlyr.assignElement(divs[i])
			dlyr.dyndoc=or

		// new line here, not sure why I did it, but it fixed a few things
		// for events I think.
			if (dyndoc.getClass()!=DynDocument) dlyr.isChild=true

			if (or.getClass()!=DynDocument) dlyr.isChild=true
			else {
		// this part was needing some fixing for Scott's new code:
				DynAPI.removeFromArray(DynLayer.unassigned, dlyr, true)
				delete DynLayer.unassignedID[dlyr.id]

				or.all[or.all.length]=dlyr
				or.all[dlyr.id]=dlyr
				or.allID[dlyr.id]=dlyr
			}

			dyndoc.children[dyndoc.children.length]=dlyr

			var index=id.indexOf("Div")
			if (index>0) dyndoc.doc.window[id.substr(0,index)] = dyndoc.all[id]

			if (is.ns4) {for (ict in dlyr.doc.images)
dlyr.doc.images[ict].lyrobj=dlyr}
			else if (is.ns5) {for (ict in dlyr.doc.images)
dlyr.doc.images[ict].lyrobj=dlyr.elm}
			else {for (ict in dlyr.elm.all.tags("img"))
dlyr.elm.all.tags("img")[ict].lyrobj=dlyr}

			if (dlyr.updateValues) dlyr.updateValues()

			DynAPI.findLayers(dlyr,or)
		}
	}
}
DynLayer.prototype.updateValues=function() {
	if (is.ns) {
		this.x=parseInt(this.css.left)
		this.y=parseInt(this.css.top)
		this.w=is.ns4? this.css.clip.width : parseInt(this.css.width)
		this.h=is.ns4? this.css.clip.height : parseInt(this.css.height)
		if (is.ns4)
this.clip=[this.css.clip.top,this.css.clip.right,this.css.clip.bottom,this.c
ss.clip.left]
		this.bgColor = this.doc.bgColor!="this.doc.bgColor"?this.doc.bgColor:null
		this.bgImage = this.elm.background.src!=""?this.elm.background.src:null
		this.html = this.innerHTML = this.elm.innerHTML = ""
	}
	else if (is.ie) {
		this.x=this.elm.offsetLeft
		this.y=this.elm.offsetTop
		this.w=is.ie4? this.css.pixelWidth : this.elm.offsetWidth
		this.h=is.ie4? this.css.pixelHeight : this.elm.offsetHeight
		this.bgImage = this.css.backgroundImage
		this.bgColor = this.css.backgroundColor
		this.html = this.innerHTML = this.elm.innerHTML
	}
	this.z = this.css.zIndex
	var b = this.css.visibility
	this.visible = (b=="inherit"||b=="show"||b=="visible"||b=="")
}
DynAPI.getModel=function() {
	dom='DYNAPI OBJECT MODEL:\n\n+DynAPI\n'
	for (var i=0; i<DynAPI.documents.length; i++) {
		dom+='  +'+DynAPI.documents[i].toString()+'\n'
		for (var j=0; j<DynAPI.documents[i].all.length; j++)
dom+='+'+DynAPI.documents[i].all[j].toString()+'\n'
	}
	alert(dom)
}
DynAPI.isDirectChildOf = function(l, parent) {
	if(is.ns) return (l.parentLayer == parent)
	for(var p=l.parentElement;p;p=p.parentElement)
	 if(p.tagName.toLowerCase()=='div') return p==parent
	return !parent.tagName
}


Some doubts about the event code in the current release, there is some code
for the
old rtmouseup and rtmousedown events.. don't think they are needed (at least
not in that
state) I've got the following solution working:

Use all of Scott's  this.button  changes, and change the handleEvent()
method into this:

EventListener.prototype.handleEvent=function(type,e)

	if (type=='mousedown' || type=='mouseup') {
		if (e.button==2) type='md'+type
		if (e.button==3) type='rt'+type
	}
	if (this["on"+type]) this["on"+type](e)
}

should do correct event bubbling, and still make different events for
rtmouseup/rtmousedown
and mdmouseup/mdmousedown (middle button)


that's it for now.. have fun :)

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

Re: [Dynapi-Dev] Widgets (was [no subject])

[Robert R. <rra...@ya...>]

I'm not quite sure I follow your DynAPI.makeWidget.  Could you explain
that in a little more detail.  I don't understand what makeWidget is
trying to do there.


Robert

-- 
Email: <mailto:rra...@ya...>
PGP Key ID: 0x703D7F7C

> I've been thinking about this for some tome now and our main problem here is
> having all our widgets to share the DynLayer functionalities without sharing any
> properties. We need some sort of initialization code such as:
> 
> myWidget = function() {
>     // Init code
> 
>     // Assign id
>     this.id = ...
> 
>     // Widget stuff starts here
> 
> }
> 
> // Maybe not anymore
> myWidget.prototype
> 
> 
> However hard-coding it into all our widgets is a pain and when we need to change
> something then we have to edit all of your widgets and we force people to
> 'remember' whet has to be placed at the beggining of each constructor. I thing
> this can be solved by having this method (this is the idea, I haven't been able
> to code it)
> 
> DynAPI.makeWidget = function(constructor) {
> var code = window[constructor].toString()
> // now we have the code
> var header = code.substring(0,code.indexOf("{"))
> var rest = code.substring(code.indexOf("{"))
> var newcode = header + have all the common init stuff in a String here + rest
> eval(constructor+" = "+newcode)
> 
> // If needed attach prototying, assign variables, etc.
> }
> 
> 
> This way your widget code should be independent of the inheritance method
> adopted. This I presume, I haven't tested. Tell me what you think
> 

Re: [Dynapi-Dev] (no subject)

[Jordi 'I. M. <jmi...@or...>]

I've been thinking about this for some tome now and our main problem here is
having all our widgets to share the DynLayer functionalities without sharing any
properties. We need some sort of initialization code such as:

myWidget = function() {
    // Init code

    // Assign id
    this.id = ...

    // Widget stuff starts here

}

// Maybe not anymore
myWidget.prototype


However hard-coding it into all our widgets is a pain and when we need to change
something then we have to edit all of your widgets and we force people to
'remember' whet has to be placed at the beggining of each constructor. I thing
this can be solved by having this method (this is the idea, I haven't been able
to code it)

DynAPI.makeWidget = function(constructor) {
var code = window[constructor].toString()
// now we have the code
var header = code.substring(0,code.indexOf("{"))
var rest = code.substring(code.indexOf("{"))
var newcode = header + have all the common init stuff in a String here + rest
eval(constructor+" = "+newcode)

// If needed attach prototying, assign variables, etc.
}


This way your widget code should be independent of the inheritance method
adopted. This I presume, I haven't tested. Tell me what you think

Re: [Dynapi-Dev] (no subject)

[Robert R. <rai...@us...>]

Hi,

I beleive there is a bug in the patch:

DynDocument.prototype.recreateAll=function() {
        this.setBgColor(this.bgColor)
        this.setFgColor(this.fgColor)      
        if (this.children) return     //<- should be (!this.children)
        for (var i in this.children) { 
                if (this.children[i].created) {  
                        if (this.children[i].elm) this.children[i].elm=null
                        this.children[i].deleteElement()
                        this.children[i].createElement()
                }
        }
}

Also, I think that you need to use the hasChildren method instead,
because if you add a child and then remove it, the .children will be
true, but have a length of zero.  So, I would sugget using the
hasChildren check instead.

Later,
Robert <rai...@us...>


> I think I've found a fix for the problem with children arrays being shared
> between widgets made with the widgetX  model.
> 
> The problem:
> 
> Widget.prototype = new DynLayer()
> 
> When this is done, the properties of the base DynLayer are *shared* with
> every Widget made with the constructor.
> 
> Most of these shared properties are reassigned to unique ones when
> createElement is called on the Widget.  However, the children array is not,
> and it gives the effect that all Widgets share the same children array.
> 
> So I've posted a patch for DynLayer and DynDocument that assigns the
> this.children array only when you use addChild.  DynLayer-based widgets
> won't have a children array until you add at least one child.
> 
> I also made changes to removeChild, removeAllChildren, etc. that check for
> the existence of the child array before proceeding.
> 
> This should ensure that the children array is a unique object for each
> widget, and not the common one in the Widget prototype.  Then you can safely
> use WidgetX to simulate inheritance without the shared-properties problem.
> 
> The only consideration is if you build a widget that manipulates the
> children array, you should test it it exists first (it's initially set to
> null until you use addChild).
> 
> I've only tested it on a few IBS and GUI widgets, but it seems to work
> across the board.  I've posted the patch for review.
> 
> scottandrew
> 
> 
> 
> 
> 
> 
> ------
> Scott Andrew LePera
> DHTML / Scripting / CGI and other neat stuff
> sc...@sc...
> http://www.scottandrew.com
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

RE: [Dynapi-Dev] Scott's mouse events

[Pascal B. <pa...@dy...>]

Hmm, I hadn't thought about the bubbling not working..

maybe if we change the handleEvent() to something like this (Warning
untested code:)

EventListener.prototype.handleEvent=function(type,e)

 if (e.button==3 && (e.type=='mouseup'  || e.type=='mousedown')) {
    if (this["onrt"+type]) this["onrt"+type](e)
 } else {
    if (this["on"+type]) this["on"+type](e)
 }
}

not sure if that would make the bubbling work ok, it won't change the mouse
events
(same as using simply the  button property) but it will still invoke another
event
which can then be created seperatly in the code.

I figure it's better to use different event listeners for different events,
and
right-mouse button should be handled seperatly from a left-mouse button
(it's the
little things in life :)


I'll try the above code and see if it works ok..

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


-----Oorspronkelijk bericht-----
Van: dyn...@li...
[mailto:dyn...@li...]Namens Scott Andrew LePera
Verzonden: zondag 29 oktober 2000 19:21
Aan: dyn...@li...
Onderwerp: Re: [Dynapi-Dev] Scott's mouse events


I think it's a matter of personal preference.  In *normal* browser events,
there is no "rtmousedown"; you have to check for the button code anyway and
branch from there.

On the other hand, there are no "onmove" and "ondragend" events either :-)
so there is a case for having special mouse handlers as well.

I guess the one thing I'd mention is that changing the type property also
changes how the event will bubble.  If you change "mousedown" to
"onrtmousedown" based on the button, the event will not bubble to other
objects listening for mousedown.

What do the other people on the list think?  Is there a way we could have
both?

scottandrew


-----Original Message-----
From: Pascal Bestebroer <pa...@dy...>
To: Dev <dyn...@li...>
Date: Sunday, October 29, 2000 6:18 AM
Subject: [Dynapi-Dev] Scott's mouse events


I like the button property Scott added, but I think it's "cleaner" if you
use different
methods for different mouse buttons.. (making it backward compatible with
the old mouse events)

As a patch you can add these lines :

 if (this.button==2) this.type='md'+this.type
 if (this.button==3) this.type='rt'+this.type

after the this.button=  line in the mouseevents. This makes the event type
rtmouseup or rtmousedown
and also adds the  mdmouseup and mdmousedown  for the middle-mouse button.

This makes any code using many eventlisteners better to debug, having
different events for different
mouse buttons (and not one event with and if (button=1)  code, which is a
bit slower)

Important question: Who's now maintaining the official" version Robert?

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

RE: [Dynapi-Dev] (no subject)

[Pascal B. <pa...@dy...>]

Ok,

I'll update the widget tutorial part so that it uses this
syntax for the widgets (using superClass)



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



-----Oorspronkelijk bericht-----
Van: dyn...@li...
[mailto:dyn...@li...]Namens Scott Andrew
LePera
Verzonden: zondag 29 oktober 2000 20:07
Aan: dyn...@li...
Onderwerp: Re: [Dynapi-Dev] (no subject)


I like that idea, and it seems to work.  I would propose some standard
syntax:

function Widget() {
  this.superClass = DynLayer
  this.superClass()
  ...
}

I think that's easier to understand than "this.DynLayer=DynLayer"...what
DynLayer? :-)












-----Original Message-----
From: Pascal Bestebroer <pa...@dy...>
To: dyn...@li... <dyn...@li...>
Date: Sunday, October 29, 2000 4:49 AM
Subject: RE: [Dynapi-Dev] (no subject)


>I think there's another way of solving this..  By slightly changing the
>way widgets are created (still using the same inheriting methods)
>
>here's an example:
>
>
>function CoreButton(x,y,w,h,caption,flat) {
> this.DynLayer = DynLayer
> this.DynLayer()
>
> this.id = "CoreButton"+(CoreButton.Count++)
>
> this.moveTo(x||0,y||0)
> this.setSize(w||128,h||36)
>
> this.caption=caption||''
>
> this.lcaption=new DynLayer(null,2,2)
> this.levents=new DynLayer(null,0,0)
>
> this.lcaption.setVisible(true)
> this.levents.setVisible(true)
>
> this.setFlat(flat||false)
> this.setVisible(true)
>
> this.style=new CoreStyle()
>
> this.children=[]
>
> return this
>}
>CoreButton.Count=0
>CoreButton.prototype = new DynLayer()
>
>The first lines in the constructor show the main change, I actually think
>somebody
>else had already mentioned this a while back but I didn't look at it then
:(
>
>This is actually the way Netscape is talking about creating objects on the
>tutorial sites.
>
>I think this solves the problem with the children array, so that no changes
>are needed to
>the dynlayer constructor. The widget will still be an "enhancded" dynlayer.
>
>I've also been working on benchmark / test code and I'll try to post it so
>that people
>can look at it and run some tests in other browsers.
>
>Pascal Bestebroer
>pa...@dy...
>http://www.dynamic-core.net
>
>
>
>
>_______________________________________________
>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

RE: [Dynapi-Dev] Template center

[Jordan L. <jo...@ex...>]

thanks for the comments.
i'm holding off for a few more comments, than i'll post an update.

-----Original Message-----
From: dyn...@li...
[mailto:dyn...@li...]On Behalf Of Darin
Kadrioski
Sent: Sunday, October 29, 2000 9:23 PM
To: 'dyn...@li...'
Subject: re: [Dynapi-Dev] Template center 



Thought I might throw my two cents in here.

I've created a small js file that handles the rendering of the property,
methods and events tables.  I think it makes writing and maintaining such
pages a bit cleaner.

You can pick it up here:

http://www.nebiru.com/dynapi2/docs_plus_methods.zip

there is an example in there for a component called TButton.

Essentially nothing changes, you just include the documentation "engine":
<script language="Javascript" src="../include/docs.js"></script>

and then add and render the values you want shown:

<script>
  clearMethods()
  addMethod('reDraw()','','Used to force a refresh.')
  renderMethods()

  clearEvents()
  addEvent('onClick()','Occurs after an onMouseUp event on the button.')
  renderEvents()
</script>


Great work on getting this template done Jordan!
_______________________________________________
Dynapi-Dev mailing list
Dyn...@li...
http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

re: [Dynapi-Dev] Template center

[Darin K. <dka...@ef...>]

Thought I might throw my two cents in here.

I've created a small js file that handles the rendering of the property,
methods and events tables.  I think it makes writing and maintaining such
pages a bit cleaner.

You can pick it up here:

http://www.nebiru.com/dynapi2/docs_plus_methods.zip

there is an example in there for a component called TButton.

Essentially nothing changes, you just include the documentation "engine":
<script language="Javascript" src="../include/docs.js"></script>

and then add and render the values you want shown:

<script>
  clearMethods()
  addMethod('reDraw()','','Used to force a refresh.')
  renderMethods()

  clearEvents()
  addEvent('onClick()','Occurs after an onMouseUp event on the button.')
  renderEvents()
</script>


Great work on getting this template done Jordan!