From: Pascal B. <pa...@dy...> - 2000-10-30 18:40:35
|
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 |
From: Scott A. L. <sc...@sc...> - 2000-10-30 22:20:36
|
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 |
From: Scott A. L. <sc...@sc...> - 2000-10-30 22:25:52
|
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 |
From: Robert R. <rra...@ya...> - 2000-10-30 22:36:42
|
> 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 |
From: Robert R. <rra...@ya...> - 2000-10-30 22:43:51
|
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 |
From: Pascal B. <pa...@dy...> - 2000-10-31 19:22:09
|
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 |
From: Scott A. L. <sc...@sc...> - 2000-10-30 23:14:40
|
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 |
From: Robert R. <rra...@ya...> - 2000-10-30 23:56:02
|
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 |