Menu
▾
▴
dynapi-dev — List related to the current DynAPI Core development
You can subscribe to this list here.
| 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
|
|
From: Pascal B. <pa...@dy...> - 2001-02-22 19:11:46
|
<complain mode> use dynapi-help for this :) </complain mode> Pascal Bestebroer pa...@dy... http://www.dynamic-core.net > -----Oorspronkelijk bericht----- > Van: dyn...@li... > [mailto:dyn...@li...]Namens Randy Hawkins > Verzonden: donderdag 22 februari 2001 19:47 > Aan: dyn...@li... > Onderwerp: [Dynapi-Dev] Using DynAPI II with Frontpage 98 problem > > > Hey, > I have looked around in the archives and have not come across an answer. > Maybe it's not there or I just missed it...anyway...I have just > downloaded > DynAPI II (dynapi-2001-01-25), and imported all of the source > files into my > existing project which is in MS FrontPage 98. When I try to preview the > following, I get an error stating that DynLayer is undefined (Line: > myLayer=new DynLayer()). If I load the same page from outside > FP, it works > fine. It seems pretty evident to me that FP is having a hard > time with the > js code. Can anyone provide insight or am I just hosed? > > Thanks, > Randy > > <html><head><title>New Page 1</title> > <script language="JavaScript1.2" src="../src/dynapi.js"></script> > <script language="JavaScript1.2"> > DynAPI.setLibraryPath('../src/lib/') > DynAPI.include('dynapi.api.browser.js') > DynAPI.include('dynapi.api.dynlayer.js') > DynAPI.include('dynapi.api.dyndocument.js') > DynAPI.onLoad=function() { > myLayer=new DynLayer() > myLayer.setSize(100,100) > myLayer.setBgColor('#c0c0c0') > myLayer.moveTo(100,100) > DynAPI.document.addChild(myLayer) > } > </script> > </head><body></body></html> > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > |
|
From: Doug M. <do...@cr...> - 2001-02-22 18:56:10
|
It does not seem that you are doing anything wrong. (imho)
So, my guess would be that it is FP..
Possible solution:
Switch:
DynAPI.include('dynapi.api.browser.js')
With:
<script language="JavaScript1.2" src="../src/lib/api/browser.js"></script>
do this for all of the includes and it may work.
You could do this in FP and use normal includes
when not in FP.
No promisses tho..
Tip for converting from .include's to <script>'s
'dynapi.api.browser.js'
translates into:
LibraryPath + "api/browser.js"
or :
'../src/lib/api/browser.js'
> Hey,
> I have looked around in the archives and have not come across an answer.
> Maybe it's not there or I just missed it...anyway...I have just downloaded
> DynAPI II (dynapi-2001-01-25), and imported all of the source files into
my
> existing project which is in MS FrontPage 98. When I try to preview the
> following, I get an error stating that DynLayer is undefined (Line:
> myLayer=new DynLayer()). If I load the same page from outside FP, it
works
> fine. It seems pretty evident to me that FP is having a hard time with
the
> js code. Can anyone provide insight or am I just hosed?
>
> Thanks,
> Randy
>
> <html><head><title>New Page 1</title>
> <script language="JavaScript1.2" src="../src/dynapi.js"></script>
> <script language="JavaScript1.2">
> DynAPI.setLibraryPath('../src/lib/')
> DynAPI.include('dynapi.api.browser.js')
> DynAPI.include('dynapi.api.dynlayer.js')
> DynAPI.include('dynapi.api.dyndocument.js')
> DynAPI.onLoad=function() {
> myLayer=new DynLayer()
> myLayer.setSize(100,100)
> myLayer.setBgColor('#c0c0c0')
> myLayer.moveTo(100,100)
> DynAPI.document.addChild(myLayer)
> }
> </script>
> </head><body></body></html>
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>
---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01
|
|
From: Randy H. <ran...@ho...> - 2001-02-22 18:46:05
|
Hey,
I have looked around in the archives and have not come across an answer.
Maybe it's not there or I just missed it...anyway...I have just downloaded
DynAPI II (dynapi-2001-01-25), and imported all of the source files into my
existing project which is in MS FrontPage 98. When I try to preview the
following, I get an error stating that DynLayer is undefined (Line:
myLayer=new DynLayer()). If I load the same page from outside FP, it works
fine. It seems pretty evident to me that FP is having a hard time with the
js code. Can anyone provide insight or am I just hosed?
Thanks,
Randy
<html><head><title>New Page 1</title>
<script language="JavaScript1.2" src="../src/dynapi.js"></script>
<script language="JavaScript1.2">
DynAPI.setLibraryPath('../src/lib/')
DynAPI.include('dynapi.api.browser.js')
DynAPI.include('dynapi.api.dynlayer.js')
DynAPI.include('dynapi.api.dyndocument.js')
DynAPI.onLoad=function() {
myLayer=new DynLayer()
myLayer.setSize(100,100)
myLayer.setBgColor('#c0c0c0')
myLayer.moveTo(100,100)
DynAPI.document.addChild(myLayer)
}
</script>
</head><body></body></html>
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
|
|
From: Pascal B. <pa...@dy...> - 2001-02-22 17:45:13
|
Hmm.. Just noticed I'm not using any of that code in dynacore.. (went back to old addchild() code) not sure, but I think I don't have problems with anything... other thought, can't we set the .dyndoc in the createelement? (already done for "top-level" child layers -they get the doc property according to the parent) and child layers are created after that, so could then have there dyndoc set. strange... needs some looking into I guess. Pascal Bestebroer pa...@dy... http://www.dynamic-core.net > -----Oorspronkelijk bericht----- > Van: dyn...@li... > [mailto:dyn...@li...]Namens Robert Rainwater > Verzonden: donderdag 22 februari 2001 18:09 > Aan: DynAPI Development List > Onderwerp: Re[2]: [Dynapi-Dev] DynAPI current things > > > > We have that with the .doc property. The problem is that it doesnt > know its .doc until the top level dynlayer has been added to the > document using addchild. So when the top level layer is added, it > then goes through all the children to set the .doc. > > Perhaps we can remove the .doc property and replace it with a > getDocument(). Then, the traversing is only done when someone requests > the document of a layer. > > > > -- > // Robert Rainwater > > On 2/22/2001, 2:44:51 PM EST, Doug wrote about "[Dynapi-Dev] > DynAPI current things": > > > would it make things any bigger > > if each layer has a this.rootDoc property? > > This would allow you to avoid having to > > > "search all the way to the top of the chain" > > > no? > > ----- Original Message ----- > > From: "Robert Rainwater" <rra...@ya...> > > To: "DynAPI Development List" <dyn...@li...> > > Sent: Thursday, February 22, 2001 8:41 AM > > Subject: Re: [Dynapi-Dev] DynAPI current things > > > >> > >> One of the things that can slow down layer creation when you have lots > >> of children it the addChildID. The reason for this method is because > >> it has to search all the way to the top of the chain to find out who > >> is dyndoc is. If we can find a way to set the dyndoc during the > >> addChild is would speed up things a lot. > >> > >> -- > >> // Robert Rainwater > >> > >> On 2/22/2001, 6:40:37 AM EST, Pascal wrote about "[Dynapi-Dev] DynAPI > > current things": > >> > >> > Here's a list of thing I want to change in the current > DynAPI code. I'm > > not > >> > searching for long discussions here, but I want to hear some (short) > >> > opinions and mainly from the people actually involved in the > > development. > >> > >> > >> > * Do some speed optimisations > >> > Mainly changes to the createElement as I did on dynacore as test, and > > seem > >> > to speed things up very nicely, without breaking code. also some > > checking > >> > on why the latest release is so much slower (have to test this for > > myself > >> > though because haven't seen it myself, just from others) > >> > >> > * DOM defaults > >> > All "if (is.xx) else..." statements should be changed so that the NS6 > > code > >> > is always the default (basically, no NS6 check should be left in the > > code). > >> > This should prove first steps towards support for true DOM compliant > >> > browsers (they should then work for a large part) > >> > >> > * Better object arrangement > >> > Split event code up for mouseevents/normalevent-invoking > (like Michael > > did). > >> > And also split DynLayer/DynDocument into > DynObject/DynLayer/DynDocument > > as > >> > did in dynacore. Should prove to be easier to "get into the > code" with > >> > DynObject handling ALL parent/child relations, and DynLayer > only doing > > that > >> > what it should: dynamic layers handling. > >> > >> > * addChild() change > >> > AddChild currently supports multiple children as parameter > at once.. no > > body > >> > uses it, no body should. Removing support for that should also give a > > slight > >> > speed increase (the child is already supplied as parameter to the > > function, > >> > so I think it will be seen as a local variable) no need to > walk thru an > >> > array, which is an extra loop not needed. the support for multiple > > children > >> > adding at once, could be created by users them self..not very hard to > > do. > >> > >> > * DynDocuments adding to DynAPI > >> > All DynDocuments should be child objects of the DynAPI > object, this way > > you > >> > get a true DynAPI tree which can be used to access ANY > object created by > > the > >> > DynAPI.. Only code that needs to be changed for this by users is code > > that > >> > used frames (the dyndocument generated should become > >> > DynAPI.addChild(dyndocument-name)) Should also prove handy in any > >> > memory-cleaning needed. > >> > >> > >> > I'm planning on doing the first two points this weekend and > possible a > > few > >> > others.. the only thing that will be time consuming is the "Better > > object > >> > arrangement" (means ALOT of testing to see if nothing got broken) > >> > >> > Any, helpful, takes on these ideas are welcome.. but please > don't make > > this > >> > a long discussion thread.. if some one doesn't like it we can discuss > > it, > >> > but otherwise I'll start on it this weekend (unless some one > else does > > it > >> > before that :) > >> > >> > >> > >> > Pascal Bestebroer (pb...@oi...) > >> > Software ontwikkelaar > >> > Oberon Informatiesystemen b.v. > >> > http://www.oibv.com > >> > >> > >> > _______________________________________________ > >> > Dynapi-Dev mailing list > >> > Dyn...@li... > >> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > >> > >> > >> ---------------------- > >> DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/ > >> DynAPI Homepage: http://dynapi.sourceforge.net/ > >> > >> > >> > >> _______________________________________________ > >> Dynapi-Dev mailing list > >> Dyn...@li... > >> http://lists.sourceforge.net/lists/listinfo/dynapi-dev > >> > > > > --- > > Outgoing mail is certified Virus Free by AVG Free Edition > > Download at: http://www.grisoft.com/html/us_index.cfm > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01 > > > > _______________________________________________ > > Dynapi-Dev mailing list > > Dyn...@li... > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > > > ---------------------- > DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/ > DynAPI Homepage: http://dynapi.sourceforge.net/ > > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > |
|
From: Doug M. <do...@cr...> - 2001-02-22 17:09:27
|
that sounds like a distinct possiblity > > We have that with the .doc property. The problem is that it doesnt > know its .doc until the top level dynlayer has been added to the > document using addchild. So when the top level layer is added, it > then goes through all the children to set the .doc. > > Perhaps we can remove the .doc property and replace it with a > getDocument(). Then, the traversing is only done when someone requests > the document of a layer. > > > > -- > // Robert Rainwater > > On 2/22/2001, 2:44:51 PM EST, Doug wrote about "[Dynapi-Dev] DynAPI current things": > > > would it make things any bigger > > if each layer has a this.rootDoc property? > > This would allow you to avoid having to > > > "search all the way to the top of the chain" > > > no? > > ----- Original Message ----- > > From: "Robert Rainwater" <rra...@ya...> > > To: "DynAPI Development List" <dyn...@li...> > > Sent: Thursday, February 22, 2001 8:41 AM > > Subject: Re: [Dynapi-Dev] DynAPI current things > > > >> > >> One of the things that can slow down layer creation when you have lots > >> of children it the addChildID. The reason for this method is because > >> it has to search all the way to the top of the chain to find out who > >> is dyndoc is. If we can find a way to set the dyndoc during the > >> addChild is would speed up things a lot. > >> > >> -- > >> // Robert Rainwater > >> > >> On 2/22/2001, 6:40:37 AM EST, Pascal wrote about "[Dynapi-Dev] DynAPI > > current things": > >> > >> > Here's a list of thing I want to change in the current DynAPI code. I'm > > not > >> > searching for long discussions here, but I want to hear some (short) > >> > opinions and mainly from the people actually involved in the > > development. > >> > >> > >> > * Do some speed optimisations > >> > Mainly changes to the createElement as I did on dynacore as test, and > > seem > >> > to speed things up very nicely, without breaking code. also some > > checking > >> > on why the latest release is so much slower (have to test this for > > myself > >> > though because haven't seen it myself, just from others) > >> > >> > * DOM defaults > >> > All "if (is.xx) else..." statements should be changed so that the NS6 > > code > >> > is always the default (basically, no NS6 check should be left in the > > code). > >> > This should prove first steps towards support for true DOM compliant > >> > browsers (they should then work for a large part) > >> > >> > * Better object arrangement > >> > Split event code up for mouseevents/normalevent-invoking (like Michael > > did). > >> > And also split DynLayer/DynDocument into DynObject/DynLayer/DynDocument > > as > >> > did in dynacore. Should prove to be easier to "get into the code" with > >> > DynObject handling ALL parent/child relations, and DynLayer only doing > > that > >> > what it should: dynamic layers handling. > >> > >> > * addChild() change > >> > AddChild currently supports multiple children as parameter at once.. no > > body > >> > uses it, no body should. Removing support for that should also give a > > slight > >> > speed increase (the child is already supplied as parameter to the > > function, > >> > so I think it will be seen as a local variable) no need to walk thru an > >> > array, which is an extra loop not needed. the support for multiple > > children > >> > adding at once, could be created by users them self..not very hard to > > do. > >> > >> > * DynDocuments adding to DynAPI > >> > All DynDocuments should be child objects of the DynAPI object, this way > > you > >> > get a true DynAPI tree which can be used to access ANY object created by > > the > >> > DynAPI.. Only code that needs to be changed for this by users is code > > that > >> > used frames (the dyndocument generated should become > >> > DynAPI.addChild(dyndocument-name)) Should also prove handy in any > >> > memory-cleaning needed. > >> > >> > >> > I'm planning on doing the first two points this weekend and possible a > > few > >> > others.. the only thing that will be time consuming is the "Better > > object > >> > arrangement" (means ALOT of testing to see if nothing got broken) > >> > >> > Any, helpful, takes on these ideas are welcome.. but please don't make > > this > >> > a long discussion thread.. if some one doesn't like it we can discuss > > it, > >> > but otherwise I'll start on it this weekend (unless some one else does > > it > >> > before that :) > >> > >> > >> > >> > Pascal Bestebroer (pb...@oi...) > >> > Software ontwikkelaar > >> > Oberon Informatiesystemen b.v. > >> > http://www.oibv.com > >> > >> > >> > _______________________________________________ > >> > Dynapi-Dev mailing list > >> > Dyn...@li... > >> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > >> > >> > >> ---------------------- > >> DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/ > >> DynAPI Homepage: http://dynapi.sourceforge.net/ > >> > >> > >> > >> _______________________________________________ > >> Dynapi-Dev mailing list > >> Dyn...@li... > >> http://lists.sourceforge.net/lists/listinfo/dynapi-dev > >> > > > > --- > > Outgoing mail is certified Virus Free by AVG Free Edition > > Download at: http://www.grisoft.com/html/us_index.cfm > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01 > > > > _______________________________________________ > > Dynapi-Dev mailing list > > Dyn...@li... > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > > > ---------------------- > DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/ > DynAPI Homepage: http://dynapi.sourceforge.net/ > > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev --- Outgoing mail is certified Virus Free by AVG Free Edition Download at: http://www.grisoft.com/html/us_index.cfm Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01 |
|
From: Robert R. <rra...@ya...> - 2001-02-22 17:06:09
|
We have that with the .doc property. The problem is that it doesnt know its .doc until the top level dynlayer has been added to the document using addchild. So when the top level layer is added, it then goes through all the children to set the .doc. Perhaps we can remove the .doc property and replace it with a getDocument(). Then, the traversing is only done when someone requests the document of a layer. -- // Robert Rainwater On 2/22/2001, 2:44:51 PM EST, Doug wrote about "[Dynapi-Dev] DynAPI current things": > would it make things any bigger > if each layer has a this.rootDoc property? > This would allow you to avoid having to > "search all the way to the top of the chain" > no? > ----- Original Message ----- > From: "Robert Rainwater" <rra...@ya...> > To: "DynAPI Development List" <dyn...@li...> > Sent: Thursday, February 22, 2001 8:41 AM > Subject: Re: [Dynapi-Dev] DynAPI current things >> >> One of the things that can slow down layer creation when you have lots >> of children it the addChildID. The reason for this method is because >> it has to search all the way to the top of the chain to find out who >> is dyndoc is. If we can find a way to set the dyndoc during the >> addChild is would speed up things a lot. >> >> -- >> // Robert Rainwater >> >> On 2/22/2001, 6:40:37 AM EST, Pascal wrote about "[Dynapi-Dev] DynAPI > current things": >> >> > Here's a list of thing I want to change in the current DynAPI code. I'm > not >> > searching for long discussions here, but I want to hear some (short) >> > opinions and mainly from the people actually involved in the > development. >> >> >> > * Do some speed optimisations >> > Mainly changes to the createElement as I did on dynacore as test, and > seem >> > to speed things up very nicely, without breaking code. also some > checking >> > on why the latest release is so much slower (have to test this for > myself >> > though because haven't seen it myself, just from others) >> >> > * DOM defaults >> > All "if (is.xx) else..." statements should be changed so that the NS6 > code >> > is always the default (basically, no NS6 check should be left in the > code). >> > This should prove first steps towards support for true DOM compliant >> > browsers (they should then work for a large part) >> >> > * Better object arrangement >> > Split event code up for mouseevents/normalevent-invoking (like Michael > did). >> > And also split DynLayer/DynDocument into DynObject/DynLayer/DynDocument > as >> > did in dynacore. Should prove to be easier to "get into the code" with >> > DynObject handling ALL parent/child relations, and DynLayer only doing > that >> > what it should: dynamic layers handling. >> >> > * addChild() change >> > AddChild currently supports multiple children as parameter at once.. no > body >> > uses it, no body should. Removing support for that should also give a > slight >> > speed increase (the child is already supplied as parameter to the > function, >> > so I think it will be seen as a local variable) no need to walk thru an >> > array, which is an extra loop not needed. the support for multiple > children >> > adding at once, could be created by users them self..not very hard to > do. >> >> > * DynDocuments adding to DynAPI >> > All DynDocuments should be child objects of the DynAPI object, this way > you >> > get a true DynAPI tree which can be used to access ANY object created by > the >> > DynAPI.. Only code that needs to be changed for this by users is code > that >> > used frames (the dyndocument generated should become >> > DynAPI.addChild(dyndocument-name)) Should also prove handy in any >> > memory-cleaning needed. >> >> >> > I'm planning on doing the first two points this weekend and possible a > few >> > others.. the only thing that will be time consuming is the "Better > object >> > arrangement" (means ALOT of testing to see if nothing got broken) >> >> > Any, helpful, takes on these ideas are welcome.. but please don't make > this >> > a long discussion thread.. if some one doesn't like it we can discuss > it, >> > but otherwise I'll start on it this weekend (unless some one else does > it >> > before that :) >> >> >> >> > Pascal Bestebroer (pb...@oi...) >> > Software ontwikkelaar >> > Oberon Informatiesystemen b.v. >> > http://www.oibv.com >> >> >> > _______________________________________________ >> > Dynapi-Dev mailing list >> > Dyn...@li... >> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev >> >> >> ---------------------- >> DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/ >> DynAPI Homepage: http://dynapi.sourceforge.net/ >> >> >> >> _______________________________________________ >> Dynapi-Dev mailing list >> Dyn...@li... >> http://lists.sourceforge.net/lists/listinfo/dynapi-dev >> > --- > Outgoing mail is certified Virus Free by AVG Free Edition > Download at: http://www.grisoft.com/html/us_index.cfm > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01 > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev ---------------------- DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/ DynAPI Homepage: http://dynapi.sourceforge.net/ |
|
From: Richard B. <ma...@ri...> - 2001-02-22 16:56:21
|
I'm trying to get this working, but I get this error (IE+NS) what am I doing
wrong?
------------------------------------------------------------
JavaScript Error: file:///C|/My Documents/My Webs/dhtml/daily
snapshots/Copy (2) of dynapi3/dynapi/src/lib/afroapi/file/url.js,
line 6:
unable to reflect applet "urlLoad", index 0 - not loaded yet?.
---------------------------------------------------------
This is the source;
----------------------------------------------------------
<script language="Javascript" src="../src/dynapi.js"></script>
<script language="Javascript">
DynAPI.setLibraryPath('../src/lib/');
DynAPI.include('dynapi.api.*');
DynAPI.include('afroapi.file.io');
DynAPI.include('afroapi.file.url');
</script>
<script language="Javascript">
DynAPI.onLoad = function() {
block = new DynLayer(null,200,200,200,200);
DynAPI.document.addChild(block);
block.setURL('../clock.html')
};
</script>
----------------------------------------------------------
Thanks,
Richard.
----- Original Message -----
From: "Michael Pemberton" <mp...@ph...>
To: <dyn...@li...>
Sent: Thursday, February 22, 2001 6:09 AM
Subject: [Dynapi-Dev] Dynamic Content Loading (IT WORKS)
> I now have it working in both NS and IE (only win tested) and can't see
> any bugs. (I should open my eyes)
>
> Just place all the files in their own directory called "file" in your
> libs directory.
>
> Then all DynLayer's will have a new method called setURL:
> DynLayer.prototype.setURL=function(url,js,noevt)
>
> url is the location of the file.
> this can be relative to the current main page or absolute.
> it MUST only be on the current domain, java does not allow external
> server downloads
> js
> do you wish any found javascript to be executed?
> noevt
> do you wish the load events to be triggered?
>
> --
> Michael Pemberton
> mp...@ph...
> ICQ: 12107010
>
>
|
|
From: Doug M. <do...@cr...> - 2001-02-22 16:46:17
|
would it make things any bigger if each layer has a this.rootDoc property? This would allow you to avoid having to "search all the way to the top of the chain" no? ----- Original Message ----- From: "Robert Rainwater" <rra...@ya...> To: "DynAPI Development List" <dyn...@li...> Sent: Thursday, February 22, 2001 8:41 AM Subject: Re: [Dynapi-Dev] DynAPI current things > > One of the things that can slow down layer creation when you have lots > of children it the addChildID. The reason for this method is because > it has to search all the way to the top of the chain to find out who > is dyndoc is. If we can find a way to set the dyndoc during the > addChild is would speed up things a lot. > > -- > // Robert Rainwater > > On 2/22/2001, 6:40:37 AM EST, Pascal wrote about "[Dynapi-Dev] DynAPI current things": > > > Here's a list of thing I want to change in the current DynAPI code. I'm not > > searching for long discussions here, but I want to hear some (short) > > opinions and mainly from the people actually involved in the development. > > > > * Do some speed optimisations > > Mainly changes to the createElement as I did on dynacore as test, and seem > > to speed things up very nicely, without breaking code. also some checking > > on why the latest release is so much slower (have to test this for myself > > though because haven't seen it myself, just from others) > > > * DOM defaults > > All "if (is.xx) else..." statements should be changed so that the NS6 code > > is always the default (basically, no NS6 check should be left in the code). > > This should prove first steps towards support for true DOM compliant > > browsers (they should then work for a large part) > > > * Better object arrangement > > Split event code up for mouseevents/normalevent-invoking (like Michael did). > > And also split DynLayer/DynDocument into DynObject/DynLayer/DynDocument as > > did in dynacore. Should prove to be easier to "get into the code" with > > DynObject handling ALL parent/child relations, and DynLayer only doing that > > what it should: dynamic layers handling. > > > * addChild() change > > AddChild currently supports multiple children as parameter at once.. no body > > uses it, no body should. Removing support for that should also give a slight > > speed increase (the child is already supplied as parameter to the function, > > so I think it will be seen as a local variable) no need to walk thru an > > array, which is an extra loop not needed. the support for multiple children > > adding at once, could be created by users them self..not very hard to do. > > > * DynDocuments adding to DynAPI > > All DynDocuments should be child objects of the DynAPI object, this way you > > get a true DynAPI tree which can be used to access ANY object created by the > > DynAPI.. Only code that needs to be changed for this by users is code that > > used frames (the dyndocument generated should become > > DynAPI.addChild(dyndocument-name)) Should also prove handy in any > > memory-cleaning needed. > > > > I'm planning on doing the first two points this weekend and possible a few > > others.. the only thing that will be time consuming is the "Better object > > arrangement" (means ALOT of testing to see if nothing got broken) > > > Any, helpful, takes on these ideas are welcome.. but please don't make this > > a long discussion thread.. if some one doesn't like it we can discuss it, > > but otherwise I'll start on it this weekend (unless some one else does it > > before that :) > > > > > Pascal Bestebroer (pb...@oi...) > > Software ontwikkelaar > > Oberon Informatiesystemen b.v. > > http://www.oibv.com > > > > _______________________________________________ > > Dynapi-Dev mailing list > > Dyn...@li... > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > > > ---------------------- > DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/ > DynAPI Homepage: http://dynapi.sourceforge.net/ > > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > --- Outgoing mail is certified Virus Free by AVG Free Edition Download at: http://www.grisoft.com/html/us_index.cfm Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01 |
|
From: Jordi - I. - M. <jmi...@or...> - 2001-02-22 16:44:32
|
I agree in all four points ( damm I can't remember not agreeing with Pascal, I wonder if it is healthy ). If browsers are moving towards DOM compliance (insert your favourite joke here) then so should the API. I'll try to give it a shot myself this weekend. We'll see. I foresee that Eytan will have plenty to say regarding the object structure, as well as many others. Please do. Quoting Richard's quote: "Don't go crazy with multiple soft levels. Keep it simple" Richard Bennett wrote: > Good points overall, > > * DOM defaults > > All "if (is.xx) else..." statements should be changed so that the NS6 code > > is always the default (basically, no NS6 check should be left in the > code). > > This should prove first steps towards support for true DOM compliant > > browsers (they should then work for a large part) > > I think DOM code should always be default, tested on the latest Mozilla > milestone, so no is.dom checks should be found, because NS6 has lots of bugs > which might require workarounds. > > Richard > > ----- Original Message ----- > From: "Pascal" <pb...@oi...> > To: <dyn...@li...> > Sent: Thursday, February 22, 2001 12:40 PM > Subject: [Dynapi-Dev] DynAPI current things > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev |
|
From: Robert R. <rra...@ya...> - 2001-02-22 16:38:56
|
One of the things that can slow down layer creation when you have lots of children it the addChildID. The reason for this method is because it has to search all the way to the top of the chain to find out who is dyndoc is. If we can find a way to set the dyndoc during the addChild is would speed up things a lot. -- // Robert Rainwater On 2/22/2001, 6:40:37 AM EST, Pascal wrote about "[Dynapi-Dev] DynAPI current things": > Here's a list of thing I want to change in the current DynAPI code. I'm not > searching for long discussions here, but I want to hear some (short) > opinions and mainly from the people actually involved in the development. > * Do some speed optimisations > Mainly changes to the createElement as I did on dynacore as test, and seem > to speed things up very nicely, without breaking code. also some checking > on why the latest release is so much slower (have to test this for myself > though because haven't seen it myself, just from others) > * DOM defaults > All "if (is.xx) else..." statements should be changed so that the NS6 code > is always the default (basically, no NS6 check should be left in the code). > This should prove first steps towards support for true DOM compliant > browsers (they should then work for a large part) > * Better object arrangement > Split event code up for mouseevents/normalevent-invoking (like Michael did). > And also split DynLayer/DynDocument into DynObject/DynLayer/DynDocument as > did in dynacore. Should prove to be easier to "get into the code" with > DynObject handling ALL parent/child relations, and DynLayer only doing that > what it should: dynamic layers handling. > * addChild() change > AddChild currently supports multiple children as parameter at once.. no body > uses it, no body should. Removing support for that should also give a slight > speed increase (the child is already supplied as parameter to the function, > so I think it will be seen as a local variable) no need to walk thru an > array, which is an extra loop not needed. the support for multiple children > adding at once, could be created by users them self..not very hard to do. > * DynDocuments adding to DynAPI > All DynDocuments should be child objects of the DynAPI object, this way you > get a true DynAPI tree which can be used to access ANY object created by the > DynAPI.. Only code that needs to be changed for this by users is code that > used frames (the dyndocument generated should become > DynAPI.addChild(dyndocument-name)) Should also prove handy in any > memory-cleaning needed. > I'm planning on doing the first two points this weekend and possible a few > others.. the only thing that will be time consuming is the "Better object > arrangement" (means ALOT of testing to see if nothing got broken) > Any, helpful, takes on these ideas are welcome.. but please don't make this > a long discussion thread.. if some one doesn't like it we can discuss it, > but otherwise I'll start on it this weekend (unless some one else does it > before that :) > Pascal Bestebroer (pb...@oi...) > Software ontwikkelaar > Oberon Informatiesystemen b.v. > http://www.oibv.com > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev ---------------------- DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/ DynAPI Homepage: http://dynapi.sourceforge.net/ |
|
From: Doug M. <do...@cr...> - 2001-02-22 16:36:55
|
no, it's not just dynapi. I'll try to come up with a good example. The reason you can't find any other, is that most leaks are in to 200 byte range. It's just that DynAPI dynamically allocates so much more ram that it's mor noticable ----- Original Message ----- From: "Lasse Lindgård" <la...@li...> To: <dyn...@li...> Sent: Thursday, February 22, 2001 4:46 AM Subject: [Dynapi-Dev] Hunting the memoryhole with a shutgun > After several attempts I still can't produce a simple example where IE5.5 > leaks without having DynAPI involved. > The create example leaks 200kb. > If you remove the DynAPI.document.addChild(myLayer) the leak stops. > I wonder what that could be ? > /Lasse > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev --- Outgoing mail is certified Virus Free by AVG Free Edition Download at: http://www.grisoft.com/html/us_index.cfm Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01 |
|
From: Doug M. <do...@cr...> - 2001-02-22 16:33:42
|
since I am insterested in anything that speeds up the API, I will help test if code is broken. (if you like) ----- Original Message ----- From: "Pascal" <pb...@oi...> To: <dyn...@li...> Sent: Thursday, February 22, 2001 3:40 AM Subject: [Dynapi-Dev] DynAPI current things > Here's a list of thing I want to change in the current DynAPI code. I'm not > searching for long discussions here, but I want to hear some (short) > opinions and mainly from the people actually involved in the development. > > > * Do some speed optimisations > Mainly changes to the createElement as I did on dynacore as test, and seem > to speed things up very nicely, without breaking code. also some checking > on why the latest release is so much slower (have to test this for myself > though because haven't seen it myself, just from others) > > * DOM defaults > All "if (is.xx) else..." statements should be changed so that the NS6 code > is always the default (basically, no NS6 check should be left in the code). > This should prove first steps towards support for true DOM compliant > browsers (they should then work for a large part) > > * Better object arrangement > Split event code up for mouseevents/normalevent-invoking (like Michael did). > And also split DynLayer/DynDocument into DynObject/DynLayer/DynDocument as > did in dynacore. Should prove to be easier to "get into the code" with > DynObject handling ALL parent/child relations, and DynLayer only doing that > what it should: dynamic layers handling. > > * addChild() change > AddChild currently supports multiple children as parameter at once.. no body > uses it, no body should. Removing support for that should also give a slight > speed increase (the child is already supplied as parameter to the function, > so I think it will be seen as a local variable) no need to walk thru an > array, which is an extra loop not needed. the support for multiple children > adding at once, could be created by users them self..not very hard to do. > > * DynDocuments adding to DynAPI > All DynDocuments should be child objects of the DynAPI object, this way you > get a true DynAPI tree which can be used to access ANY object created by the > DynAPI.. Only code that needs to be changed for this by users is code that > used frames (the dyndocument generated should become > DynAPI.addChild(dyndocument-name)) Should also prove handy in any > memory-cleaning needed. > > > I'm planning on doing the first two points this weekend and possible a few > others.. the only thing that will be time consuming is the "Better object > arrangement" (means ALOT of testing to see if nothing got broken) > > Any, helpful, takes on these ideas are welcome.. but please don't make this > a long discussion thread.. if some one doesn't like it we can discuss it, > but otherwise I'll start on it this weekend (unless some one else does it > before that :) > > > > Pascal Bestebroer (pb...@oi...) > Software ontwikkelaar > Oberon Informatiesystemen b.v. > http://www.oibv.com > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev --- Outgoing mail is certified Virus Free by AVG Free Edition Download at: http://www.grisoft.com/html/us_index.cfm Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01 |
|
From: Richard B. <ma...@ri...> - 2001-02-22 14:16:59
|
Good points overall, > * DOM defaults > All "if (is.xx) else..." statements should be changed so that the NS6 code > is always the default (basically, no NS6 check should be left in the code). > This should prove first steps towards support for true DOM compliant > browsers (they should then work for a large part) I think DOM code should always be default, tested on the latest Mozilla milestone, so no is.dom checks should be found, because NS6 has lots of bugs which might require workarounds. Richard ----- Original Message ----- From: "Pascal" <pb...@oi...> To: <dyn...@li...> Sent: Thursday, February 22, 2001 12:40 PM Subject: [Dynapi-Dev] DynAPI current things |
|
From: Jordi - I. - M. <jmi...@or...> - 2001-02-22 14:00:12
|
I agree. Pascal wrote: > the addChild() is the first point that creates an actual HTML element/object > (it adds contents to the html page) > > this would suggest that normal javascript objects are freed (also sounds > logicall, seeing the documents found by Mr.Design) using some form of > garbage collection. > > There might be a problem with javascript objects having a reference to real > html objects (layers) and that reference is still valid (so the GC won't > destroy the objects).. > > Pascal Bestebroer (pb...@oi...) > Software ontwikkelaar > Oberon Informatiesystemen b.v. > http://www.oibv.com > > > -----Oorspronkelijk bericht----- > > Van: dyn...@li... > > [mailto:dyn...@li...]Namens Lasse Lindgård > > Verzonden: donderdag 22 februari 2001 13:47 > > Aan: dyn...@li... > > Onderwerp: [Dynapi-Dev] Hunting the memoryhole with a shutgun > > > > > > After several attempts I still can't produce a simple example > > where IE5.5 > > leaks without having DynAPI involved. > > The create example leaks 200kb. > > If you remove the DynAPI.document.addChild(myLayer) the leak stops. > > I wonder what that could be ? > > /Lasse > > > > > > _______________________________________________ > > Dynapi-Dev mailing list > > Dyn...@li... > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev |
|
From: Pascal <pb...@oi...> - 2001-02-22 13:11:15
|
the addChild() is the first point that creates an actual HTML element/object (it adds contents to the html page) this would suggest that normal javascript objects are freed (also sounds logicall, seeing the documents found by Mr.Design) using some form of garbage collection. There might be a problem with javascript objects having a reference to real html objects (layers) and that reference is still valid (so the GC won't destroy the objects).. Pascal Bestebroer (pb...@oi...) Software ontwikkelaar Oberon Informatiesystemen b.v. http://www.oibv.com > -----Oorspronkelijk bericht----- > Van: dyn...@li... > [mailto:dyn...@li...]Namens Lasse Lindgård > Verzonden: donderdag 22 februari 2001 13:47 > Aan: dyn...@li... > Onderwerp: [Dynapi-Dev] Hunting the memoryhole with a shutgun > > > After several attempts I still can't produce a simple example > where IE5.5 > leaks without having DynAPI involved. > The create example leaks 200kb. > If you remove the DynAPI.document.addChild(myLayer) the leak stops. > I wonder what that could be ? > /Lasse > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > |
|
From: Michael P. <mp...@ph...> - 2001-02-22 12:48:48
|
Yes. this is what will I hope will eventually be done using my readURL method. I was suprised by his request for my source code with the intention of writing a php version. he would still require the java to comunicate with the server. if you interested, I now have dynamic library loading working in IE. NS still has problems. : ( Pascal wrote: > yes there is.. servertasks was an example of it > > you can use a hidden frame or ilayer or whatever, that loads in an ASP page > specifying parameters in the location.. (for one example, there might be > other ways) > > Pascal Bestebroer (pb...@oi...) > Software ontwikkelaar > Oberon Informatiesystemen b.v. > http://www.oibv.com > > > -----Oorspronkelijk bericht----- > > Van: dyn...@li... > > [mailto:dyn...@li...]Namens Michael > > Pemberton > > Verzonden: donderdag 22 februari 2001 13:03 > > Aan: dyn...@li... > > Onderwerp: Re: [Dynapi-Dev] Dynamic Content Loading (IT WORKS) > > > > > > Here's the source code. > > > > I don't see what you mean by a PHP version. There is no way > > of getting > > cominucation between PHP and the browser. > > > > Raymond Smith wrote: > > > > > I like this. What I see of it anyway. > > > > > > I think a js window manager + I/O manager + server apps > > could lead to some > > > real fun applications. > > > > > > Would like to see the java source (if it's an option, if > > not no problem), > > > and start working on a PHP version of this as well; adding > > in the two other > > > components. > > > > > > _______________________________________________ > > > Dynapi-Dev mailing list > > > Dyn...@li... > > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > > > > -- > > Michael Pemberton > > mp...@ph... > > ICQ: 12107010 > > > > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev -- Michael Pemberton mp...@ph... ICQ: 12107010 |
|
From: <la...@li...> - 2001-02-22 12:48:04
|
After several attempts I still can't produce a simple example where IE5.5 leaks without having DynAPI involved. The create example leaks 200kb. If you remove the DynAPI.document.addChild(myLayer) the leak stops. I wonder what that could be ? /Lasse |
|
From: Pascal <pb...@oi...> - 2001-02-22 12:25:34
|
yes there is.. servertasks was an example of it you can use a hidden frame or ilayer or whatever, that loads in an ASP page specifying parameters in the location.. (for one example, there might be other ways) Pascal Bestebroer (pb...@oi...) Software ontwikkelaar Oberon Informatiesystemen b.v. http://www.oibv.com > -----Oorspronkelijk bericht----- > Van: dyn...@li... > [mailto:dyn...@li...]Namens Michael > Pemberton > Verzonden: donderdag 22 februari 2001 13:03 > Aan: dyn...@li... > Onderwerp: Re: [Dynapi-Dev] Dynamic Content Loading (IT WORKS) > > > Here's the source code. > > I don't see what you mean by a PHP version. There is no way > of getting > cominucation between PHP and the browser. > > Raymond Smith wrote: > > > I like this. What I see of it anyway. > > > > I think a js window manager + I/O manager + server apps > could lead to some > > real fun applications. > > > > Would like to see the java source (if it's an option, if > not no problem), > > and start working on a PHP version of this as well; adding > in the two other > > components. > > > > _______________________________________________ > > Dynapi-Dev mailing list > > Dyn...@li... > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > > -- > Michael Pemberton > mp...@ph... > ICQ: 12107010 > > |
|
From: Michael P. <mp...@ph...> - 2001-02-22 12:17:19
|
the problem was that there was no method of downloading content AFTER the page has been rendered. I wanted a way of downloading the new code without the need to reload a page or use a separate frame. I also wanted a loadpanel that would allow me to access the HTML in NS after loading new content. Doc Oliver wrote: > > Would like to see the java source (if it's an option, if not no problem), > > and start working on a PHP version of this as well; adding in the two other > > components. > > Did y'all know that you can do all of this with the help of a server-side > script + some cookies ? (create img, set source to ss-file, ss-file can > read from query - writes to cookie, script reads from cookie). I was > working on something like that before, but decided to go with java. > > One problem though, there semes to be some problems with unicode and the > communication between java/js (try loading a chinese file into a chinese > document). > > my 0.02$ > > ____________________________________________________________________ > Get free email and a permanent address at http://www.amexmail.com/?A=1 > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev -- Michael Pemberton mp...@ph... ICQ: 12107010 |
|
From: Michael P. <mp...@ph...> - 2001-02-22 12:05:04
|
Here's the source code. I don't see what you mean by a PHP version. There is no way of getting cominucation between PHP and the browser. Raymond Smith wrote: > I like this. What I see of it anyway. > > I think a js window manager + I/O manager + server apps could lead to some > real fun applications. > > Would like to see the java source (if it's an option, if not no problem), > and start working on a PHP version of this as well; adding in the two other > components. > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev -- Michael Pemberton mp...@ph... ICQ: 12107010 |
|
From: <la...@li...> - 2001-02-22 11:49:05
|
I tried them too with my w2k ie55. I can't see any difference. The test that creates object without destroying them leaked around 10-80kb ram after creating 10000 objects and hitting back. That is so little that it might just be the history+cache in IE. Can someone come up with an example of a leak that doesn't use DynAPI ? /Lasse -------- Message: 7 From: "Jared Nuzzolillo" <ja...@aa...> To: <dyn...@li...> Subject: Re: [Dynapi-Dev] Continuing Freeing memory Date: Wed, 21 Feb 2001 17:26:53 -0500 Reply-To: dyn...@li... Not sure if my tests are reliable, but I tried the following, and it showed little difference: www.aavex.com/asl/memtests jaredn :: http://webfx.eae.net |
|
From: Pascal <pb...@oi...> - 2001-02-22 11:39:31
|
Here's a list of thing I want to change in the current DynAPI code. I'm not searching for long discussions here, but I want to hear some (short) opinions and mainly from the people actually involved in the development. * Do some speed optimisations Mainly changes to the createElement as I did on dynacore as test, and seem to speed things up very nicely, without breaking code. also some checking on why the latest release is so much slower (have to test this for myself though because haven't seen it myself, just from others) * DOM defaults All "if (is.xx) else..." statements should be changed so that the NS6 code is always the default (basically, no NS6 check should be left in the code). This should prove first steps towards support for true DOM compliant browsers (they should then work for a large part) * Better object arrangement Split event code up for mouseevents/normalevent-invoking (like Michael did). And also split DynLayer/DynDocument into DynObject/DynLayer/DynDocument as did in dynacore. Should prove to be easier to "get into the code" with DynObject handling ALL parent/child relations, and DynLayer only doing that what it should: dynamic layers handling. * addChild() change AddChild currently supports multiple children as parameter at once.. no body uses it, no body should. Removing support for that should also give a slight speed increase (the child is already supplied as parameter to the function, so I think it will be seen as a local variable) no need to walk thru an array, which is an extra loop not needed. the support for multiple children adding at once, could be created by users them self..not very hard to do. * DynDocuments adding to DynAPI All DynDocuments should be child objects of the DynAPI object, this way you get a true DynAPI tree which can be used to access ANY object created by the DynAPI.. Only code that needs to be changed for this by users is code that used frames (the dyndocument generated should become DynAPI.addChild(dyndocument-name)) Should also prove handy in any memory-cleaning needed. I'm planning on doing the first two points this weekend and possible a few others.. the only thing that will be time consuming is the "Better object arrangement" (means ALOT of testing to see if nothing got broken) Any, helpful, takes on these ideas are welcome.. but please don't make this a long discussion thread.. if some one doesn't like it we can discuss it, but otherwise I'll start on it this weekend (unless some one else does it before that :) Pascal Bestebroer (pb...@oi...) Software ontwikkelaar Oberon Informatiesystemen b.v. http://www.oibv.com |
|
From: Raymond S. <dst...@or...> - 2001-02-22 10:08:51
|
Whatever happened to Labcoats pending "Super-Optimizied-Twin-Turbofied-Dynosmooooth" version of the API he was preparing to present in a couple of days 3 weeks ago? |
|
From: Doc O. <doc...@us...> - 2001-02-22 08:52:58
|
> Would like to see the java source (if it's an option, if not no problem= ), > and start working on a PHP version of this as well; adding in the two o= ther > components. Did y'all know that you can do all of this with the help of a server-side= script + some cookies ? (create img, set source to ss-file, ss-file can read from query - writes to cookie, script reads from cookie). I was working on something like that before, but decided to go with java. One problem though, there semes to be some problems with unicode and the communication between java/js (try loading a chinese file into a chinese document). my 0.02$ ____________________________________________________________________ Get free email and a permanent address at http://www.amexmail.com/?A=3D1 |
|
From: Raymond S. <dst...@or...> - 2001-02-22 08:43:08
|
I like this. What I see of it anyway. I think a js window manager + I/O manager + server apps could lead to some real fun applications. Would like to see the java source (if it's an option, if not no problem), and start working on a PHP version of this as well; adding in the two other components. |
175 messages has been excluded from this view by a project administrator.
