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: Raymond S. <dst...@or...> - 2000-12-02 10:09:51
|
Sorry, second uses a "viewport". ----- Original Message ----- From: "Raymond Smith" <dst...@or...> To: <dyn...@li...> Sent: Saturday, December 02, 2000 2:01 AM Subject: [Dynapi-Dev] proteanman getContentWidth()&Height feedback. > Tested patch on both win98, me. Netscape 6,4 > > 4 is fine, but our beta-site has two nested > (layer-->layer-->layer[pushpanel]) Second one is just a nested oversized > image. Niether register and propagate. > > Cheers > > DS > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev > |
|
From: Raymond S. <dst...@or...> - 2000-12-02 10:06:01
|
Tested patch on both win98, me. Netscape 6,4 4 is fine, but our beta-site has two nested (layer-->layer-->layer[pushpanel]) Second one is just a nested oversized image. Niether register and propagate. Cheers DS |
|
From: Pascal B. <pa...@dy...> - 2000-12-02 09:11:06
|
please do! have never used winCVS (familiair with freeVCS which might not be compatible yet does the same thing). Pascal Bestebroer pa...@dy... http://www.dynamic-core.net > -----Oorspronkelijk bericht----- > Van: dyn...@li... > [mailto:dyn...@li...]Namens Robert Rainwater > Verzonden: zaterdag 2 december 2000 4:17 > Aan: Dan Steinman > Onderwerp: Re: [Dynapi-Dev] Lets open CVS again > > > > If the group would like, I can give instructions on how to setup CVS > in Windows. Its really just a matter of downloading and setting up > WinCVS and ssh. I've never used cvs in linux, but if you do, you need > to make sure you have ssh setup. > > There are also a few howto docs at sourceforge on how to use CVS for > new users. > > -- > // Robert Rainwater > > On Saturday, December 02, 2000, 12:17:47 AM, Dan wrote: > > > I really think we should open up CVS again to do our > development. As it is it's not easy for everyone to contribute > code, and Robert is stuck with the job of collecting everything > and making an > > official release. Using CVS will make it easier on everyone. > > > We can help eachother to get it all set up on local computers, > and make sure we can all release files easily. There's CVS > clients for Windows (CVSWin?) that should be pretty easy to use. > > > It'll also make it easy for non-developers to get the latest > code without searching around for everything. > > > This weekend I'll get a Makefile/build scheme working which > will compress all the js code, jar it for Netscape, and repackage > it all. And this should be the starting point for the new dynapi CVS > > tree. > > > Dan > > _______________________________________________ > > 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 > |
|
From: Robert R. <rra...@ya...> - 2000-12-02 03:14:48
|
If the group would like, I can give instructions on how to setup CVS in Windows. Its really just a matter of downloading and setting up WinCVS and ssh. I've never used cvs in linux, but if you do, you need to make sure you have ssh setup. There are also a few howto docs at sourceforge on how to use CVS for new users. -- // Robert Rainwater On Saturday, December 02, 2000, 12:17:47 AM, Dan wrote: > I really think we should open up CVS again to do our development. As it is it's not easy for everyone to contribute code, and Robert is stuck with the job of collecting everything and making an > official release. Using CVS will make it easier on everyone. > We can help eachother to get it all set up on local computers, and make sure we can all release files easily. There's CVS clients for Windows (CVSWin?) that should be pretty easy to use. > It'll also make it easy for non-developers to get the latest code without searching around for everything. > This weekend I'll get a Makefile/build scheme working which will compress all the js code, jar it for Netscape, and repackage it all. And this should be the starting point for the new dynapi CVS > tree. > Dan > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev |
|
From: Robert R. <rra...@ya...> - 2000-12-02 03:08:37
|
> in netscape 6 never call a DynLayer "title": > title = new DynLayer() This is true with many reserved variable names. Also, never do: mylayer = DynAPI.document.all["mylayer"] -- // Robert Rainwater On Friday, December 01, 2000, 8:16:02 PM, Nicola wrote: > Nothing to be worried about just a suggestion > in netscape 6 never call a DynLayer "title": > title = new DynLayer() > it won't work > also scroll doesn't work for IE and layer for netscape 4 > ciao > Nicola > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev |
|
From: Nicola M. <nma...@hs...> - 2000-12-02 01:18:51
|
Nothing to be worried about just a suggestion in netscape 6 never call a DynLayer "title": title = new DynLayer() it won't work also scroll doesn't work for IE and layer for netscape 4 ciao Nicola |
|
From: Dan S. <dy...@fu...> - 2000-12-01 23:53:20
|
I really think we should open up CVS again to do our development. As it is it's not easy for everyone to contribute code, and Robert is stuck with the job of collecting everything and making an official release. Using CVS will make it easier on everyone. We can help eachother to get it all set up on local computers, and make sure we can all release files easily. There's CVS clients for Windows (CVSWin?) that should be pretty easy to use. It'll also make it easy for non-developers to get the latest code without searching around for everything. This weekend I'll get a Makefile/build scheme working which will compress all the js code, jar it for Netscape, and repackage it all. And this should be the starting point for the new dynapi CVS tree. Dan |
|
From: Robert R. <rra...@ya...> - 2000-12-01 19:03:42
|
When you use DynAPI.include(), you do not have to put the .js extension
with the current implementation. The reason it is done in the
addLibrary is so it does not have to be concatenated on each library
item in the for loop.
So, it is more efficient to add the .js to the files in addLibrary (this
is usually done internally in the DynAPI, anyways). And, currently the
.js is not required in the include(). So, I don't see a reason to
change this. I don't think any other solution will be quite as fast as
now (unless you require the .js).
--
// Robert Rainwater
On Sat, 02 Dec 2000 02:48:28 +1100
Michael Pemberton <mp...@ph...> wrote:
> Does anyone here name their javascript files with any extension other than.js?I only ask this because I find it annoying that I have to put .js atthe end of each library entry and also in all of the include lines.Surely it is easier if you just place .js in the include code and thenwe don't have to worry about it ever again.Here's what I'm talking about: include : function(src,path) {
> if(src.substring(src.length-3)!=".js")src+=src.substring(0,src.length-3)
> if (!path) var path=DynAPI.librarypath
> var pckg=src.substring(0,src.indexOf('.'))
> var groupname=src.substring(src.indexOf('.')+1)
> var realsrc=groupname.substring(groupname.indexOf('.')+1)
> groupname=groupname.substring(0,groupname.indexOf('.'))
> if (src.indexOf('.*')>0){
> src=src.substring(0,src.indexOf('.*'))
> if (DynAPI.packages[pckg]) group=DynAPI.packages[pckg].libs[groupname]
> if (group) for (var i in group) document.write('<script language="Javascript1.2"_
> src="'+path+pckg+'/'+groupname+'/'+group[i]+'.js"><\/script>')
> else alert(DynAPI.toString()+'\n\nError occured\nThe following packagecould not_
> be loaded:\n'+src+'\n\nmake sure you specified the correct path.')
> } else document.write('<scriptLanguage="Javascript1.2"_
> src="'+path+pckg+'/'+groupname+'/'+realsrc+'.js"><\/script>')
> }
> DynAPI.addLibrary('dynapi.api',["dynlayer","browser","dyndocument","events","dragevent"])
> I know this is not as important as getting the bugs worked out, butit does make it alot more "MS User" friendly. (what, the files have extensions?: P )
> --
> Michael Pemberton
> mp...@ph...
> ICQ: 12107010_______________________________________________Dynapi-Dev mailing lis...@li...http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
|
|
From: Michael P. <mp...@ph...> - 2000-12-01 17:02:05
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
The code I posted earlier was too quickly cut and paste.
<p>Here's the correct code:
<p><tt>include : function(src,path) {</tt>
<br><tt> if(src.substring(src.length-3)==".js") src=src.substring(0,src.length-3)</tt>
<br><tt> if (!path) var path=DynAPI.librarypath</tt>
<br><tt> var groupname=src.substring(src.indexOf('.')+1)</tt>
<br><tt> var realsrc=groupname.substring(groupname.indexOf('.')+1)</tt>
<br><tt> groupname=groupname.substring(0,groupname.indexOf('.'))</tt>
<br><tt> if (src.indexOf('.*')>0) {</tt>
<br><tt> src=src.substring(0,src.indexOf('.*'))</tt>
<br><tt> if (DynAPI.packages[pckg])
var group=DynAPI.packages[pckg][groupname]</tt>
<br><tt> if (group) for (var
i in group) document.write('<script language="Javascript1.2" src="'+path+pckg+'/'+groupname+'/'+group[i]+'.js"><\/script>')</tt>
<br><tt> } else document.write('<script language="Javascript1.2"
src="'+path+pckg+'/'+groupname+'/'+realsrc+'.js"><\/script>')</tt>
<br><tt>}</tt><tt></tt>
<p><tt>DynAPI.addLibrary('dynapi.api',["dynlayer","browser","dyndocument","events","dragevent"])</tt>
<p>--
<br>Michael Pemberton
<br>mp...@ph...
<br>ICQ: 12107010</html>
|
|
From: Dan S. <dy...@fu...> - 2000-12-01 16:13:59
|
Notes:
- I don't understand why can't you do getImage() before onLoad. Does this effect DynAPI.getImage() in images.js also? It all works fine in Netscape. I will investigate it.
- Label unwrap was removed, it is no longer needed really, I just forgot to take it out of the example file. The text selecting problem is IE specific, I know there is a method that will stop text selecting on a div, this code would be put into Label.setSelectable(). And yes, certainly the border option can be done.
- I quietly rezipped my file after I initially posted my message, I fixed some of the scrolling problems in ViewPort/ScrollBar. Perhaps download the file again and see if it was the same as you downloaded.
- The adding and removing of DynLayers is handled by DynLayer, it would not be a problem specific to my widgets. That problem doesn't affect the Netscape version, so I am almost positive that this is a DynLayer/IE specific bug.
- ImageAnim is definately a good replacement for GifAnim, it has a few features that were not available before like adding several animations, and selectively switching between them at any time, and to play the animations in "alternating" mode where it plays forward/backward/forward... No memory leaks as far as I can tell. You'll see a great application of it in my bumblebee demo when I fix it.
Dan
On Thu, Nov 30, 2000 at 02:58:44PM +0100, Richard :o) wrote:
> Hi,
> First and foremost, thanks to you Dan, and the other developers for sharing
> your hard work with us, it is really appreciated.
> Your new animation widgets are incredible, I'll be up all night trying them.
>
> I gave your examples a quick test, and include my buglist here: (I noticed
> in the source you are aware of most of these)
> Tested on winMe IE5.5 500p3.
>
> Buglist:
>
> * text select problem in button.js - needs coverLayer or something.
>
> * in Dynimage demo : (uimg-dimg-limg-rimg incuded after DynAPI.onLoad):
>
> DynAPI.onLoad = function() {
> uimg = DynImage.getImage('../js/lib/dynapi/images/common/arrowup.gif');
> dimg = DynImage.getImage('../js/lib/dynapi/images/common/arrowdown.gif');
> limg = DynImage.getImage('../js/lib/dynapi/images/common/arrowleft.gif');
> rimg = DynImage.getImage('../js/lib/dynapi/images/common/arrowright.gif');
>
> img = new DynImage();
> img.moveTo(50,150);
> img.setSize(16,16);
> img.setImageSrc('../js/lib/dynapi/images/common/arrowright.gif');
>
> DynAPI.document.addChild(img);
> }
>
> * in Label - non-wrappable lable doesn't resize or unwrap (causes error)
> + non-selectable doesn't work
> + why not make table-border-width user definable?(instead of inserting a
> second table for the border)
>
> * in PushPanel: scroll doesn't stop anymore
> + the pushpanel seems to delete the labels after use, instead of hiding
> them, so you can only view a label once.
>
> * ScrollPane: Rename all instances of scroll to scrollBar (someone had a
> lot of problems with this)
> +Move 'MetalScrollPaneURL = "../js/lib/dynapi/images/scrollpane/"' after
> DynAPI.onload
> +same problem as pushpanel with deleting labels.
>
> * ViewPort : same problem as pushpanel with deleting labels.
>
> * ImgeAnim : I had to include the arrows array declaring, after
> DynAPI.onload.
> +What's memory leakage performance like? is it a good replacement for
> animated gif?
>
> end of buglist
>
> Cheers,
> Richard :o)
>
>
> ----- Original Message -----
> From: "Dan Steinman" <dy...@fu...>
> To: <dyn...@li...>
> Sent: Friday, December 01, 2000 12:44 PM
> Subject: [Dynapi-Dev] New Animation System
>
>
> > My latest code can be downloaded from:
> >
> > http://fury161.dyndns.org/dynapi-11.12-dan.zip
> >
> > Robert R, can you just take this zip file and make it the "latest beta"?
> BTW, I think we should open CVS up again and make a little tutorial on how
> to use it for our dev team.
> >
> > This is the 11.12 beta release, plus my widgets, plus the changes I
> mentioned yesterday, plus some small fixes to LoadPanel.
> >
> > The new animation system is ready to use (aside from one slide bug that I
> just noticed before posting this message).
> >
> > You have the following new animation objects:
> >
> > Thread - a small timer objects, other animation objects extend thread (so
> they are all threads and work similarly)
> >
> > PathAnimation - a new Path animation system that replaces Slide animation
> > CircleAnimation - moves a layer in a circle
> > HoverAnimation - moves a layer in a hovering motion
> > ImageAnimation - equivalent to what used to be GifAnim in Dynapi
> >
> > The PathAnimation file also includes a very small DynLayer extention for
> doing slide animations. There is only .slideTo(x,y,inc,speed), and
> .stopSlide() methods. This extention merely creates a path animation on the
> fly and plays it immediately. Instead of firing slidestart, slide, and
> slideend events, PathAnimation will call pathstart, pathrun, and pathstop
> respectivly.
> >
> > I also made a DynImage widget that is basically what Jordi had created a
> while go, it is needed for ImageAnimation. As well I've decided to scrap
> the Sprite widget for the time being. I was going to make Sprite the only
> way to do slides, and include the image support, but I think splitting it
> into a DynLayer extention and the DynImage widget is a more desirable
> structure.
> >
> > ScrollBar and ViewPort needed minor fixes due to the Slide change. In
> doing this I noticed my new Slide animation code was not 100% right, the
> Scrollbar is a little flakey at the moment. I'll go over it again and iron
> that bug out. After that change the "slide.js" code can be deprecated.
> This new code is far far superior.
> >
> > I made demos for each of the new objects so you can see for yourself how
> they work.
> >
> > I have to go back and update my Solar and BumbleBee demos again, they show
> a real-world application of this code and it works extremely well.
> >
> > Any questions/comments, feel free to post em...
> >
> > Dan
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> > ____________________________________________________________
> > Get your FREE personal .com domain name and
> > NAMEzero Personal Portal at: http://www.namezero.com.
> > For customer service, mailto:cus...@na....
> >
> >
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
|
|
From: Michael P. <mp...@ph...> - 2000-12-01 15:50:38
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Does anyone here name their javascript files with any extension other than
.js?
<p>I only ask this because I find it annoying that I have to put .js at
the end of each library entry and also in all of the include lines.
<p>Surely it is easier if you just place .js in the include code and then
we don't have to worry about it ever again.
<p>Here's what I'm talking about:<tt></tt>
<p><tt> include : function(src,path) {</tt>
<br><tt> if(src.substring(src.length-3)!=".js")
src+=src.substring(0,src.length-3)</tt>
<br><tt> if (!path) var path=DynAPI.librarypath</tt>
<br><tt> var pckg=src.substring(0,src.indexOf('.'))</tt>
<br><tt> var groupname=src.substring(src.indexOf('.')+1)</tt>
<br><tt> var realsrc=groupname.substring(groupname.indexOf('.')+1)</tt>
<br><tt> groupname=groupname.substring(0,groupname.indexOf('.'))</tt>
<br><tt> if (src.indexOf('.*')>0)
{</tt>
<br><tt>
src=src.substring(0,src.indexOf('.*'))</tt>
<br><tt>
if (DynAPI.packages[pckg]) group=DynAPI.packages[pckg].libs[groupname]</tt>
<br><tt>
if (group) for (var i in group) document.write('<script language="Javascript1.2"_</tt>
<br><tt>
src="'+path+pckg+'/'+groupname+'/'+group[i]+'<b>.js</b>"><\/script>')</tt>
<br><tt>
else alert(DynAPI.toString()+'\n\nError occured\nThe following package
could not_</tt>
<br><tt>
be loaded:\n'+src+'\n\nmake sure you specified the correct path.')</tt>
<br><tt> } else document.write('<script
Language="Javascript1.2"_</tt>
<br><tt>
src="'+path+pckg+'/'+groupname+'/'+realsrc+'<b>.js</b>"><\/script>')</tt>
<br><tt> }</tt><tt></tt>
<p><tt> DynAPI.addLibrary('dynapi.api',["dynlayer","browser","dyndocument","events","dragevent"])</tt><tt></tt>
<p>I know this is not as important as getting the bugs worked out, but
it does make it alot more "MS User" friendly. (what, the files have extensions?
: P )
<p>--
<br>Michael Pemberton
<br>mp...@ph...
<br>ICQ: 12107010</html>
|
|
From: Robert R. <rra...@ya...> - 2000-12-01 15:16:06
|
I've uploaded the beta release to http://dynapi.sourceforge.net/beta/dynapi-12.01-beta.zip. It includes Dan's new animation widgets. Please reply with any bugs to this thread. Known Bug: The DynAPI.addLibrary() calls in dynapi.js need to be changed to reflect the new files and organization. -- // Robert Rainwater |
|
From: Richard :o\) <ma...@ri...> - 2000-12-01 14:38:47
|
Hi,
First and foremost, thanks to you Dan, and the other developers for sharing
your hard work with us, it is really appreciated.
Your new animation widgets are incredible, I'll be up all night trying them.
I gave your examples a quick test, and include my buglist here: (I noticed
in the source you are aware of most of these)
Tested on winMe IE5.5 500p3.
Buglist:
* text select problem in button.js - needs coverLayer or something.
* in Dynimage demo : (uimg-dimg-limg-rimg incuded after DynAPI.onLoad):
DynAPI.onLoad = function() {
uimg = DynImage.getImage('../js/lib/dynapi/images/common/arrowup.gif');
dimg = DynImage.getImage('../js/lib/dynapi/images/common/arrowdown.gif');
limg = DynImage.getImage('../js/lib/dynapi/images/common/arrowleft.gif');
rimg = DynImage.getImage('../js/lib/dynapi/images/common/arrowright.gif');
img = new DynImage();
img.moveTo(50,150);
img.setSize(16,16);
img.setImageSrc('../js/lib/dynapi/images/common/arrowright.gif');
DynAPI.document.addChild(img);
}
* in Label - non-wrappable lable doesn't resize or unwrap (causes error)
+ non-selectable doesn't work
+ why not make table-border-width user definable?(instead of inserting a
second table for the border)
* in PushPanel: scroll doesn't stop anymore
+ the pushpanel seems to delete the labels after use, instead of hiding
them, so you can only view a label once.
* ScrollPane: Rename all instances of scroll to scrollBar (someone had a
lot of problems with this)
+Move 'MetalScrollPaneURL = "../js/lib/dynapi/images/scrollpane/"' after
DynAPI.onload
+same problem as pushpanel with deleting labels.
* ViewPort : same problem as pushpanel with deleting labels.
* ImgeAnim : I had to include the arrows array declaring, after
DynAPI.onload.
+What's memory leakage performance like? is it a good replacement for
animated gif?
end of buglist
Cheers,
Richard :o)
----- Original Message -----
From: "Dan Steinman" <dy...@fu...>
To: <dyn...@li...>
Sent: Friday, December 01, 2000 12:44 PM
Subject: [Dynapi-Dev] New Animation System
> My latest code can be downloaded from:
>
> http://fury161.dyndns.org/dynapi-11.12-dan.zip
>
> Robert R, can you just take this zip file and make it the "latest beta"?
BTW, I think we should open CVS up again and make a little tutorial on how
to use it for our dev team.
>
> This is the 11.12 beta release, plus my widgets, plus the changes I
mentioned yesterday, plus some small fixes to LoadPanel.
>
> The new animation system is ready to use (aside from one slide bug that I
just noticed before posting this message).
>
> You have the following new animation objects:
>
> Thread - a small timer objects, other animation objects extend thread (so
they are all threads and work similarly)
>
> PathAnimation - a new Path animation system that replaces Slide animation
> CircleAnimation - moves a layer in a circle
> HoverAnimation - moves a layer in a hovering motion
> ImageAnimation - equivalent to what used to be GifAnim in Dynapi
>
> The PathAnimation file also includes a very small DynLayer extention for
doing slide animations. There is only .slideTo(x,y,inc,speed), and
.stopSlide() methods. This extention merely creates a path animation on the
fly and plays it immediately. Instead of firing slidestart, slide, and
slideend events, PathAnimation will call pathstart, pathrun, and pathstop
respectivly.
>
> I also made a DynImage widget that is basically what Jordi had created a
while go, it is needed for ImageAnimation. As well I've decided to scrap
the Sprite widget for the time being. I was going to make Sprite the only
way to do slides, and include the image support, but I think splitting it
into a DynLayer extention and the DynImage widget is a more desirable
structure.
>
> ScrollBar and ViewPort needed minor fixes due to the Slide change. In
doing this I noticed my new Slide animation code was not 100% right, the
Scrollbar is a little flakey at the moment. I'll go over it again and iron
that bug out. After that change the "slide.js" code can be deprecated.
This new code is far far superior.
>
> I made demos for each of the new objects so you can see for yourself how
they work.
>
> I have to go back and update my Solar and BumbleBee demos again, they show
a real-world application of this code and it works extremely well.
>
> Any questions/comments, feel free to post em...
>
> Dan
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> ____________________________________________________________
> Get your FREE personal .com domain name and
> NAMEzero Personal Portal at: http://www.namezero.com.
> For customer service, mailto:cus...@na....
>
>
|
|
From: Joachim L. <lu...@ho...> - 2000-12-01 11:21:56
|
Why do I constantly fire my mouth before the brains have come up to speed?
setTimeout("alert(document.getElementById('lyr').offsetWidth)", 0);
/Lunna
At 2000-12-01 12:01 , you wrote:
>The offsetWidth/Height of the layer will give the right answer, but only if
>you allow the rendering machine to kick in. A bug to be fixed, actually.
>
>(Nothing DynAPI here:)
>alert(setTimeout("element.offsetWidth", 0)); // timeout in 0 msecs
>
>If only there was some way to force it to recalc the values...
>
>/Lunna
>
>
>At 2000-12-01 00:58 , you wrote:
>>I'm having problem using the getContentWidth() and getContentHeight in
>>netscape 6
>>It looks like the value that are returned are wrong
>>does anyone have had the same problem or any idea on how to solve it?
>>
>>thank you
>>Nicola
>>_______________________________________________
>>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
|
|
From: Joachim L. <lu...@ho...> - 2000-12-01 11:02:00
|
The offsetWidth/Height of the layer will give the right answer, but only if
you allow the rendering machine to kick in. A bug to be fixed, actually.
(Nothing DynAPI here:)
alert(setTimeout("element.offsetWidth", 0)); // timeout in 0 msecs
If only there was some way to force it to recalc the values...
/Lunna
At 2000-12-01 00:58 , you wrote:
>I'm having problem using the getContentWidth() and getContentHeight in
>netscape 6
>It looks like the value that are returned are wrong
>does anyone have had the same problem or any idea on how to solve it?
>
>thank you
>Nicola
>_______________________________________________
>Dynapi-Dev mailing list
>Dyn...@li...
>http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
|
|
From: Barre B. <ba...@ho...> - 2000-12-01 10:16:18
|
> I have completed splitting the API into parts for IE and NS, even to their > specific versions. I have nodiced a 10x increase in speed. And a great > increase in stability. I believe that the current API model is a very sound and applicable one. It is coherent and easily followed. But.... Speed and stability easily outweigh ease of implementation. This I have concluded trying to create complicated webapps in dHtml. Another thing is that a split would decrease the amount of browser checking in the API, which would also speed things up. > If the community was to appoint a maintainer for each browser, someone who > is highly sufficient in the capabilities of the browser, then they can > optimize their versions without fear of gumming up the works for other > browsers and platforms. This is a VERY valid point. Trying to keep platform compatability intact while developing is a royal pain in the ass. > I'm not staying it will be easy. But I believe that the benifits would > outway the work it would entail. This I totally agree with. / Bart > ----- Original Message ----- > From: "Abel Eduardo Cantu Salas" <abe...@al...> > To: <dyn...@li...> > Sent: Thursday, November 30, 2000 2:00 PM > Subject: RE: [Dynapi-Dev] inheritance crusade / SuperClass stuff > > > > > But isn't it better to use optimised versions for the browser, not > > > the one for all? > > > > It sound very interesting indeed Alexey... then you can also create new js > > for newer browsers whithout any need to touch other js (just like dlls or > > device drivers, you'll load what you need); it will allow you to reduce > the > > amount of code that the client most download and most important than that > is > > the fact that this code will be really very optimised. However this has an > > important drawback that we most consider: > > > > Doing this means an extra work in trying to maintain standardized all the > > APIS for diferent platforms and diferent browsers, id est, if we add > > something to an API we must add the same functionality to all other; and > not > > just that, separating everything so you can then optimize a lot, could > make > > easy a loss of control in what is disponible for what platform. > > > > Im sure we don't want a DynAPI that says: "this is disponible only for NS" > > or vice versa, then we most work a lot to keep things in the right path. > > > > Any opinions or sugestions about this matter?, there is a lot of > advantages > > and drawbacks in a schema like this... > > > > -----Original Message----- > > From: dyn...@li... > > [mailto:dyn...@li...]On Behalf Of Alexey > > Medvedev > > Sent: Jueves, 30 de Noviembre de 2000 10:42 a.m. > > To: dyn...@li... > > Subject: Re: Re: Re: [Dynapi-Dev] inheritance crusade / SuperClass stuff > > > > > > On Thu, 30 Nov 2000, Barre Bizon wrote: > > > > Yes - I told it is JS_1.3_ > > > > > Another thing... neither the function.call() nor the > > > function.apply() method work under IE4+. > > > Unfortunately. > > > > Also add .watch() to the list :-/ > > > > But isn't it better to use optimised versions for the brouser, not > > the one for all? > > > > So main "dynapi" whould be a selector of "dynlayer_ns4.js" > > or "dynlayer_ie4.js" but keeping same API? > > > > I thinks using "new Layer" in NN4 is better then creating > > lots of CSS and <div>-s (memory usage and resistance to Resize): > > > > http://deep.kiev.ua/JS/WebGram/ - resize resistant without > > any reloads. > > > > ps. last one i need to make site as one page , with changed layers > > Same as www.htmlguru.com is. > > > > Malx > > > > _______________________________________________ > > 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 |
|
From: Alexey M. <ma...@ca...> - 2000-12-01 09:07:13
|
> Doing this means an extra work in trying to maintain standardized all the Yes. One of the solution is to make test-examples. So you must run this tests every time (automatically , like Pascals test wizard). But it is really a problem. > something to an API we must add the same functionality to all other; and not But. We could separate wich part is independent (DynLayer API) and which is dependent (the dynlayer.js). So widgets have no dependent parts at all. > Im sure we don't want a DynAPI that says: "this is disponible only for NS" > or vice versa, then we most work a lot to keep things in the right path. Of course :))) Malx -- There is no thing in the world, which is more powerfull, than default |
|
From: Siegel, D. <DS...@ai...> - 2000-12-01 07:16:24
|
Hy! >I'm having problem using the getContentWidth() and getContentHeight in >netscape 6. Netscape 6 seems to be unable to deal with Layers which has no height and width properties. You has to set the width and height before the NC 6 has to render it. With layers and inline layers, you could use the .setSize methode. Ciao Dirk Siegel |
|
From: Dan S. <dy...@fu...> - 2000-12-01 06:20:48
|
My latest code can be downloaded from: http://fury161.dyndns.org/dynapi-11.12-dan.zip Robert R, can you just take this zip file and make it the "latest beta"? BTW, I think we should open CVS up again and make a little tutorial on how to use it for our dev team. This is the 11.12 beta release, plus my widgets, plus the changes I mentioned yesterday, plus some small fixes to LoadPanel. The new animation system is ready to use (aside from one slide bug that I just noticed before posting this message). You have the following new animation objects: Thread - a small timer objects, other animation objects extend thread (so they are all threads and work similarly) PathAnimation - a new Path animation system that replaces Slide animation CircleAnimation - moves a layer in a circle HoverAnimation - moves a layer in a hovering motion ImageAnimation - equivalent to what used to be GifAnim in Dynapi The PathAnimation file also includes a very small DynLayer extention for doing slide animations. There is only .slideTo(x,y,inc,speed), and .stopSlide() methods. This extention merely creates a path animation on the fly and plays it immediately. Instead of firing slidestart, slide, and slideend events, PathAnimation will call pathstart, pathrun, and pathstop respectivly. I also made a DynImage widget that is basically what Jordi had created a while go, it is needed for ImageAnimation. As well I've decided to scrap the Sprite widget for the time being. I was going to make Sprite the only way to do slides, and include the image support, but I think splitting it into a DynLayer extention and the DynImage widget is a more desirable structure. ScrollBar and ViewPort needed minor fixes due to the Slide change. In doing this I noticed my new Slide animation code was not 100% right, the Scrollbar is a little flakey at the moment. I'll go over it again and iron that bug out. After that change the "slide.js" code can be deprecated. This new code is far far superior. I made demos for each of the new objects so you can see for yourself how they work. I have to go back and update my Solar and BumbleBee demos again, they show a real-world application of this code and it works extremely well. Any questions/comments, feel free to post em... Dan |
|
From: Robert R. <rra...@ya...> - 2000-12-01 01:52:08
|
Why not just create a focus manager and maybe even a focus listener. So
you could say:
focus = new FocusListener(this)
focus.onFocus = function() { //stuff here }
focus.onBlur = function() {}
....
Actually, your solution does not allow you to integrate focuses into
dynlayers. So when you are trying to create widgets or anything else,
it will not be very helpfull. It also doesn't allow you to group layers.
For instance you may want to have more than one group of dynlayers, with
each group having its own focused layer.
--
// Robert Rainwater
On Thu, 30 Nov 2000 12:09:54 -0600
Abel Eduardo Cantú Salas <abe...@al...> wrote:
> netscape... yes you are right, it doesn't works in ns as it is now; but let me see, maybe there is a way!
> im working on it right now...
>
> And dynamic objects can use this technic; if not, what is the purpose of discussing this in the list?
> However, if after some investigation it seems not possible to do something similar in every browser supported by DynAPI then i'll just abdicate and start over again with another idea. By principle, im just trying not to overcharge things.
>
> -----Original Message-----
> From: dyn...@li... [mailto:dyn...@li...]On Behalf Of Brandon Myers
> Sent: Miércoles, 29 de Noviembre de 2000 09:54 p.m.
> To: dyn...@li...
> Subject: Re: [Dynapi-Dev] Widgit creation - Tab and Focus
>
>
> of course, that only works in IE. What about netscape? And what about focusing dynamic objects?
>
> Let's work with the problem presented, and not provide a solution that can't be used.
>
> Focus manager is easy when there is a "Helper" event watcher that will capture events on all objects of a specific class.
> ----- Original Message -----
> From: Abel Eduardo Cantú Salas
> To: dyn...@li...
> Sent: Wednesday, November 29, 2000 10:09 PM
> Subject: RE: [Dynapi-Dev] Widgit creation - Tab and Focus
>
>
> Ups! this is a better version of test.htm :D
>
> -----Original Message-----
> From: dyn...@li...
> [mailto:dyn...@li...]On Behalf Of Abel Eduardo
> Cantú Salas
> Sent: Miércoles, 29 de Noviembre de 2000 08:31 p.m.
> To: dyn...@li...
> Subject: RE: [Dynapi-Dev] Widgit creation - Tab and Focus
>
>
> related to the management of keystrokes, focus and blur events in events.js
> ----------------------------------------------------------------------------
>
> My idea is less complicated (i think) and requires fewer code. Instead of
> creating a more complex object that manages a list of widgets and bubbles
> the focus events, just leave the browser window take care of it.
>
> Here is an example using dhtm (not dynapi) IMPORTANT: it works only in ie 5
> (i not warrant that this html will look fine in other browser, but maybe ie
> 5.5 or 4.x):
>
> see attached file.
> ------------------
>
> what im doing right now with dynapi is something like this:
>
> 1) saving the original DynLayer createElement in a separated pointer
> (inherited_createElement) on my widget.
> 2) overwriting this createElement method
> 2.1) in this overwrote method i call the inherited_createElement
> 2.2) after that, i add the anchor tag using insertAdjacentHTML method
>
> 3) i think thats it!
>
> Everybody requiring this functionality just will need to base their own
> widgets on this one and Presto!, we have widgets that can take focus not
> just by clicking but using the tab key also.
>
> However we need to review events.js and add the capability to manage focus,
> blur and keydown events so we can do everything just using common
> eventListeners, im still having problems there because it stills working
> only in ie. But i hope that somebody more familiar to ns will solve these
> problems someday... What i need for now is get this thing working on IE
> under a Win environment a soon as posible: A widget that copies the behavior
> of a TStringGrid (developers familiar with Delphi will know whats that) and
> time is almost over!
>
> cheers guys!
>
> -----Original Message-----
> From: dyn...@li...
> [mailto:dyn...@li...]On Behalf Of Darin
> Kadrioski
> Sent: Miércoles, 29 de Noviembre de 2000 05:57 p.m.
> To: DynAPI Dev (E-mail)
> Subject: [Dynapi-Dev] Widgit creation - Tab and Focus
>
>
>
> Heya guys,
>
> Scott and I had a brief thread going last spring about having the concept of
> "focus" shared amongst many widgits on the same page.
> This is to facilitate "tabbing" between controls and the blinking of
> "carets" for edits, etc...
>
> One thought was to have a global constructor that each widgit would
> "register" with. The Dynapi would keep a list of the widgits in the order
> they were created, this then becomes the "tab order". Assuming we can
> successfully trap the tab key in both browsers, the dynapi would catch it
> first before bubbling it to the widgets. It would then send an OnBlur()
> event to whichever control currently had focus and an OnFocus() event to the
> next in the list.
>
> Any thoughts on if this could be acheived? Anyone else see the need for it?
>
> Also, how about a "standard" construction call for widgit builders to use?
> Something like create(x,y,w,h,fgcolor,bgcolor,skin)
>
> And maybe a set of standard events.
> refresh() comes to mind.
>
>
> -cheers!
>
> --------------------------------------------------
> Darin Kadrioski
> Applications/Internet Developer
>
> > Electronic Freight Exchange, Corp.
> dka...@ef...
> (916) 933-0724 x315
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
|
|
From: Nicola M. <nma...@hs...> - 2000-12-01 00:01:10
|
I'm having problem using the getContentWidth() and getContentHeight in netscape 6 It looks like the value that are returned are wrong does anyone have had the same problem or any idea on how to solve it? thank you Nicola |
|
From: Nicola M. <nma...@hs...> - 2000-11-30 23:50:37
|
I' ve been trying to get the getContentWidth() and getContentHeight() to work in netscape 6 but it's returning wrong values do any one have a fiz for that? thank you |
|
From: Doug M. <do...@cr...> - 2000-11-30 22:14:53
|
How about posting your efforts.. an increase in speed and stability is something I think we could all use.. (well, I could anyways..) ----- Original Message ----- From: "Brandon Myers" <bnd...@ho...> To: <dyn...@li...> Sent: Thursday, November 30, 2000 11:58 AM Subject: [Dynapi-Dev] Splitting the API? > I don't know how splitting the API came out of object inheritance. Which are > 2 totally sperate issues... but here goes my wordy opinion... > > I have completed splitting the API into parts for IE and NS, even to their > specific versions. I have nodiced a 10x increase in speed. And a great > increase in stability. > > If the community was to appoint a maintainer for each browser, someone who > is highly sufficient in the capabilities of the browser, then they can > optimize their versions without fear of gumming up the works for other > browsers and platforms. > > The other drawback, from what I see, is that there would be a need to > maintain a list of files for each browser type. Or, what files are common, > and what files are specific for each browser. I have solved this problem, > but the requirement for maintaing a list of files for each category, or > browser, is still a necessity. That, although, gives a benifit to the API. > Now, we sould no-longer have to specify the fill path of the script file. > Just the name of the script would include all necessary files. If, for > example, the DynLayer object where to be split, there coujld be 5 possible > files generated. > 1: The common parts to all browsers. > 2: IE4 > 3: IE5 > 4: NS4 > 5: DOM compliant. > > The common part would obviously be the larger, as there is much that is > common to both browsers. But if things are done right, the result of the > seperation, when both common and the specific browser version is combined, > would be less than the original DynLayer file was before the split. This I > have proved with the version I have enhanced. > > It becomes quite simple to maintain after a list of standards of what the > API is actually suppoed to provide is made available. It also allows > developers who like the API, and wish to target a specific browser audience > with enhanced features not provided by other brosers, to develop highly > advcanced sites using the API together with their own proprietary additions. > These additions are made easier due to the "pluggable" nature of the > resulting split. > > Supporting browser specific implementation of features available in both > browsers also becomes easier. Things such as audio support, a file that > glues java objects to javascript events, and vice versa. These features > become trivial when this path is followed. > > I'm not staying it will be easy. But I believe that the benifits would > outway the work it would entail. > ----- Original Message ----- > From: "Abel Eduardo Cantu Salas" <abe...@al...> > To: <dyn...@li...> > Sent: Thursday, November 30, 2000 2:00 PM > Subject: RE: [Dynapi-Dev] inheritance crusade / SuperClass stuff > > > > > But isn't it better to use optimised versions for the browser, not > > > the one for all? > > > > It sound very interesting indeed Alexey... then you can also create new js > > for newer browsers whithout any need to touch other js (just like dlls or > > device drivers, you'll load what you need); it will allow you to reduce > the > > amount of code that the client most download and most important than that > is > > the fact that this code will be really very optimised. However this has an > > important drawback that we most consider: > > > > Doing this means an extra work in trying to maintain standardized all the > > APIS for diferent platforms and diferent browsers, id est, if we add > > something to an API we must add the same functionality to all other; and > not > > just that, separating everything so you can then optimize a lot, could > make > > easy a loss of control in what is disponible for what platform. > > > > Im sure we don't want a DynAPI that says: "this is disponible only for NS" > > or vice versa, then we most work a lot to keep things in the right path. > > > > Any opinions or sugestions about this matter?, there is a lot of > advantages > > and drawbacks in a schema like this... > > > > -----Original Message----- > > From: dyn...@li... > > [mailto:dyn...@li...]On Behalf Of Alexey > > Medvedev > > Sent: Jueves, 30 de Noviembre de 2000 10:42 a.m. > > To: dyn...@li... > > Subject: Re: Re: Re: [Dynapi-Dev] inheritance crusade / SuperClass stuff > > > > > > On Thu, 30 Nov 2000, Barre Bizon wrote: > > > > Yes - I told it is JS_1.3_ > > > > > Another thing... neither the function.call() nor the > > > function.apply() method work under IE4+. > > > Unfortunately. > > > > Also add .watch() to the list :-/ > > > > But isn't it better to use optimised versions for the brouser, not > > the one for all? > > > > So main "dynapi" whould be a selector of "dynlayer_ns4.js" > > or "dynlayer_ie4.js" but keeping same API? > > > > I thinks using "new Layer" in NN4 is better then creating > > lots of CSS and <div>-s (memory usage and resistance to Resize): > > > > http://deep.kiev.ua/JS/WebGram/ - resize resistant without > > any reloads. > > > > ps. last one i need to make site as one page , with changed layers > > Same as www.htmlguru.com is. > > > > Malx > > > > _______________________________________________ > > 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 > > > > |
|
From: Brandon M. <bnd...@ho...> - 2000-11-30 20:07:03
|
Well said. // Brandon ----- Original Message ----- From: "Scott Andrew LePera" <sc...@sc...> To: <dyn...@li...> Sent: Thursday, November 30, 2000 1:39 PM Subject: Re: AW: Re: [Dynapi-Dev] inheritance crusade / SuperClass stuff > I hate to beat a dead horse here, but...:-) > > Pascal's WidgetX model is perfectly fine for most applications of > DynAPI2. For most apps there's really no need to go deeper than that. > Most widgets I've seen inherit directly from DynLayer and go no further > than that, anyway. It's well-documented and easy to understand. > > On the other hand, if you prefer a stricter, Java-like inheritance model > without worrying about having to preserve methods and properties, try > using the SuperClass object. It simulates OO very well, tracks class > instances, and manages super methods. But it's a little more difficult > to use. > > So there is a choice, and you're free to choose whatever suits your > task, or create an approach of your own. I myself like the > possibilities of SuperClass but more often than not WidgetX suits my > needs just fine. And I agree that bug fixing the API is more important > at this point than choosing "one true path" for a widget model. A > correct widget model is one that works. > > -- > scott andrew lepera > ----------------------------------- > web stuff: www.scottandrew.com > music stuff: www.walkingbirds.com > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev |
|
From: Brandon M. <bnd...@ho...> - 2000-11-30 19:56:42
|
I don't know how splitting the API came out of object inheritance. Which are 2 totally sperate issues... but here goes my wordy opinion... I have completed splitting the API into parts for IE and NS, even to their specific versions. I have nodiced a 10x increase in speed. And a great increase in stability. If the community was to appoint a maintainer for each browser, someone who is highly sufficient in the capabilities of the browser, then they can optimize their versions without fear of gumming up the works for other browsers and platforms. The other drawback, from what I see, is that there would be a need to maintain a list of files for each browser type. Or, what files are common, and what files are specific for each browser. I have solved this problem, but the requirement for maintaing a list of files for each category, or browser, is still a necessity. That, although, gives a benifit to the API. Now, we sould no-longer have to specify the fill path of the script file. Just the name of the script would include all necessary files. If, for example, the DynLayer object where to be split, there coujld be 5 possible files generated. 1: The common parts to all browsers. 2: IE4 3: IE5 4: NS4 5: DOM compliant. The common part would obviously be the larger, as there is much that is common to both browsers. But if things are done right, the result of the seperation, when both common and the specific browser version is combined, would be less than the original DynLayer file was before the split. This I have proved with the version I have enhanced. It becomes quite simple to maintain after a list of standards of what the API is actually suppoed to provide is made available. It also allows developers who like the API, and wish to target a specific browser audience with enhanced features not provided by other brosers, to develop highly advcanced sites using the API together with their own proprietary additions. These additions are made easier due to the "pluggable" nature of the resulting split. Supporting browser specific implementation of features available in both browsers also becomes easier. Things such as audio support, a file that glues java objects to javascript events, and vice versa. These features become trivial when this path is followed. I'm not staying it will be easy. But I believe that the benifits would outway the work it would entail. ----- Original Message ----- From: "Abel Eduardo Cantu Salas" <abe...@al...> To: <dyn...@li...> Sent: Thursday, November 30, 2000 2:00 PM Subject: RE: [Dynapi-Dev] inheritance crusade / SuperClass stuff > > But isn't it better to use optimised versions for the browser, not > > the one for all? > > It sound very interesting indeed Alexey... then you can also create new js > for newer browsers whithout any need to touch other js (just like dlls or > device drivers, you'll load what you need); it will allow you to reduce the > amount of code that the client most download and most important than that is > the fact that this code will be really very optimised. However this has an > important drawback that we most consider: > > Doing this means an extra work in trying to maintain standardized all the > APIS for diferent platforms and diferent browsers, id est, if we add > something to an API we must add the same functionality to all other; and not > just that, separating everything so you can then optimize a lot, could make > easy a loss of control in what is disponible for what platform. > > Im sure we don't want a DynAPI that says: "this is disponible only for NS" > or vice versa, then we most work a lot to keep things in the right path. > > Any opinions or sugestions about this matter?, there is a lot of advantages > and drawbacks in a schema like this... > > -----Original Message----- > From: dyn...@li... > [mailto:dyn...@li...]On Behalf Of Alexey > Medvedev > Sent: Jueves, 30 de Noviembre de 2000 10:42 a.m. > To: dyn...@li... > Subject: Re: Re: Re: [Dynapi-Dev] inheritance crusade / SuperClass stuff > > > On Thu, 30 Nov 2000, Barre Bizon wrote: > > Yes - I told it is JS_1.3_ > > > Another thing... neither the function.call() nor the > > function.apply() method work under IE4+. > > Unfortunately. > > Also add .watch() to the list :-/ > > But isn't it better to use optimised versions for the brouser, not > the one for all? > > So main "dynapi" whould be a selector of "dynlayer_ns4.js" > or "dynlayer_ie4.js" but keeping same API? > > I thinks using "new Layer" in NN4 is better then creating > lots of CSS and <div>-s (memory usage and resistance to Resize): > > http://deep.kiev.ua/JS/WebGram/ - resize resistant without > any reloads. > > ps. last one i need to make site as one page , with changed layers > Same as www.htmlguru.com is. > > Malx > > _______________________________________________ > 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 |
175 messages has been excluded from this view by a project administrator.
