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

Re: [Dynapi-Dev] all vs. allID

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

> After Robert mentioned it, I can think of no good reason for maintaining an
> all[] and allID[] array.  I don't think there's enough benefit to justify
> having both.  As he suggested, the dyndocument could just as easily keep a
> numeric count as DynLayers are added and removed.
> 
> This would also remove potential memory leaks and speed things up a bit.
> Unless someone has other ideas, I would suggest removing the numeric all[]
> and replace it with allID, renaming it to all[], of course.

While it wouldn't be as easy, I think the same can be done for the
.children array. If it were an associative array with the indexes
being ids, it would improve the speed of deleteChild and removeChild
since they would not have to loop through all of the children. The
whole point of those loops is to verify the child exists. Then you
could just say if (this.children[id]).  Maybe just add a function
hasChildren() that returns true/false.

As far as naming, .allID should definately be renamed to .all, but of
course that would affect the way you access inline layers, so the
tutorials would need updating.


\\Robert

-- 

[Dynapi-Dev] all vs. allID

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

After Robert mentioned it, I can think of no good reason for maintaining an
all[] and allID[] array.  I don't think there's enough benefit to justify
having both.  As he suggested, the dyndocument could just as easily keep a
numeric count as DynLayers are added and removed.

This would also remove potential memory leaks and speed things up a bit.
Unless someone has other ideas, I would suggest removing the numeric all[]
and replace it with allID, renaming it to all[], of course.

------
Scott Andrew LePera
DHTML / Scripting / CGI and other neat stuff
sc...@sc...
http://www.scottandrew.com

Re: [Dynapi-Dev] Can Dan add alink to DynAPI2?

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

There is a link now located on the http://www.dansteinman.com/dynapi page.


\\Robert

-- 

[Dynapi-Dev] Can Dan add alink to DynAPI2?

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

I agree it was time for Dan to take down the V1 forum, it was really getting
out of hand.

But we are now effectivly cut off from the rest of the world.
I believe there will come a time when we may loose momentum without that
large of a developer base.

Can we talk Dan into placing a link to the sourceforge site or something?

whatever became of dynapi.org?  do we need somebody to host it?

Re: [Dynapi-Dev] Inline Layers - Events Bug in NS Using Double-Click

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

Which browser isn't the dblclick working in?  Its working on my IE 5.5
and NS 4.76.


\\Robert

-- 

RE: [Dynapi-Dev] Inline Layers - Events Bug in NS Using Double-Click

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

the double-click doesn't seem to work for normal layers either..
I recall that there was some code for dblclick timing for netscape
browsers..but can't find it in the current release..possibly the problem?

haven't looked into it yet, anybody else?

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


-----Oorspronkelijk bericht-----
Van: dyn...@li...
[mailto:dyn...@li...]Namens Robert Rainwater
Verzonden: vrijdag 3 november 2000 5:25
Aan: DynAPI Dev
Onderwerp: [Dynapi-Dev] Inline Layers - Events Bug in NS Using
Double-Click



When using inline layers, I am able to capture all mouse events except
double-click in Netscape.  In IE, it works fine.  Double-click is also
working for regular dynlayers.  So, I am assuming the problem with
double-click in NS may be in the inline.js.

Any ideas?


\\Robert

-- 


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

RE: [Dynapi-Dev] Updated dynlayer and dyndocument

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

the UpdateValues is needed, to make all the properties like x,y, w,h 
set correctly for the inline layers.

There's no need for the method to exist in the normal dynapi.js because
it's only needed when the inline.js extensions are used.

but it is used

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


-----Oorspronkelijk bericht-----
Van: dyn...@li...
[mailto:dyn...@li...]Namens Robert Rainwater
Verzonden: zondag 5 november 2000 22:07
Aan: Robert Rainwater
Onderwerp: Re: [Dynapi-Dev] Updated dynlayer and dyndocument



Actually, after looking more at dynlayer.js, there is no where that it
is even needed.  The only file that uses it is inline.js, but its not
really needed there either.  I think that the .children array should
be associative as well.  If it were, then the dynlayer could really be
more efficient.  It would just mean we would have to keep track of the
count, but thats a small price to pay.


\\Robert

-- 


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

Re: [Dynapi-Dev] Updated dynlayer and dyndocument

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

Actually, after looking more at dynlayer.js, there is no where that it
is even needed.  The only file that uses it is inline.js, but its not
really needed there either.  I think that the .children array should
be associative as well.  If it were, then the dynlayer could really be
more efficient.  It would just mean we would have to keep track of the
count, but thats a small price to pay.


\\Robert

-- 

Re: [Dynapi-Dev] Updated dynlayer and dyndocument

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

Why not just store the count and have just an allID.  In what cases do
you need to access the array by its .all array?  You can still loop
through the allID array, but it wouldn't be necessary as much as it is
now.


\\Robert

-- 

> The original idea behind the two array was to have a flexible way to
> reference DynLayers and to provide a proper toString method so you can do
> away with the eval(this.obj + "=this") trick.
> 
> all:
> 
> - allows you to check for the number of DynLayers with the .length property
> - best when used with for (var i=0;i<all.length;i++) type loop
> - useful if you ever need an ordinal reference
> 
> alID:
> 
> - allows an instant check by ID (no loop needed)
> - best when used with for (var i in all) type loop
> - easy array element deletion:  delete allID[obj.id]
> - used to return a consistent string reference:
> DynAPI.getDocument(id).allID[id]
> 
> I agree it can be a pain to manage the two arrays.

Re: [Dynapi-Dev] Updated dynlayer and dyndocument

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

The original idea behind the two array was to have a flexible way to
reference DynLayers and to provide a proper toString method so you can do
away with the eval(this.obj + "=this") trick.

all:

- allows you to check for the number of DynLayers with the .length property
- best when used with for (var i=0;i<all.length;i++) type loop
- useful if you ever need an ordinal reference

alID:

- allows an instant check by ID (no loop needed)
- best when used with for (var i in all) type loop
- easy array element deletion:  delete allID[obj.id]
- used to return a consistent string reference:
DynAPI.getDocument(id).allID[id]

I agree it can be a pain to manage the two arrays.

-----Original Message-----
From: Robert Rainwater <rra...@ya...>
To: DynAPI Dev <dyn...@li...>
Date: Saturday, November 04, 2000 10:57 PM
Subject: [Dynapi-Dev] Updated dynlayer and dyndocument


>
>I've updated the dynlayer and dyndocument so that the recreateall will
>actually work.  The biggest pain was adding children of children to
>the all array in the addChild method.  So I added a method addChildID
>that should fix the problem.  When a dynlayer thats knows its dyndoc
>or a dyndocument itself calls addchild, then that child and all of its
>children are added to the .all and .allID arrays.
>
>I've attached my dynlayer and dyndocument files.  Please let me know
>of any bugs/improvements because it hasn't been fully tested yet.
>
>Also, the method calls like oncreate that are hard coded into the
>dynlayer need to be removed.  Like:
>if (this.onCreate) { this.onCreate() }   file://<-
>
>The only problem is that they are used in some of the widgets.  So if
>we are going to remove these, everyone should make sure their widgets
>use the eventlisteners instead.
>
>Also, could someone tell me the purpose of the .all array?  I know we
>need the allID array, but the all array I just don't understand.
>
>
>\\Robert
>
>--

Re: [Dynapi-Dev] Updated dynlayer and dyndocument

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

I've noticed that Netscape does have a memory leak here.  Even though the
physical layers are destroyed on a resize or reload, Netscape keeps
incrementing the count until it dies.  I don't think NS manages it's memory
very efficiently in this regard.

scottandrew

-----Original Message-----
From: Robert Rainwater <rra...@ya...>
To: Rob Romanek <dyn...@li...>
Date: Saturday, November 04, 2000 11:31 PM
Subject: Re: [Dynapi-Dev] Updated dynlayer and dyndocument


>
>
>> Hey I just threw this into my files fired up Netscape opened up the
gui.menulist, and
>> resized away...Yeah!!! the layers are recreated....but if I keep doing
over and over,
>> the redraw of the layers slow down, until at about the 10th time it stops
redrawing,
>> is the recreateall, reusing the previous layers or creating new ones? if
it is
>> creating new ones could it be the old ones are not being killed off and
hence the
>> slowdown and freeze as you clog the browser with layers
>>
>> If you reload or move to a new page and back everything is fine so
hopefully, for now
>> users won't resize 10 times while on the same page :-)
>
>Recreateall does actually recreate the layers in Netscape.  And the
>function that is used, createElement, could probaly use some more
optimization.
>
>A lot of it could just be a Netscape memory allocation thing, too.  But, I
>see several places that the dynlayer can be fixed so that the creation
>will speed up.  Hopefully I fix some of these early next week and post
>them.  I haven't really tested my update to much, but hopefully
>someone will find some optimizations as well.
>
>\\Robert
>
>--
>
>
>_______________________________________________
>Dynapi-Dev mailing list
>Dyn...@li...
>http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>

Re: [Dynapi-Dev] Packages

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

By the way here's my changes that I made to the dynapi.js.  This
change requires that you add the directory dynapi to lib2.0/ and move
all of the dynapi gui,ext,api stuff under that directory.

If you have a package called mycore.gui.*, then to add it to the
dynapi you say:

DynAPI.addLibrary('mycore.gui',['file1.js','file2.js'])

I attached dynapi.js


\\Robert

-- 

[Dynapi-Dev] Packages

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

Another proposal I have is to add package support.  So you could have
your own packages that could have their own gui and ext classes.  That
way the directory structure would be like:

lib2.0/
  dynapi/
     api/
     ext/
     gui/
  myapi/
     gui/

I've modified my version of the dynapi.js to support this already.
This way you can separate your widgets into their own packages that
won't interfere with the dynapi package.  This will make the dynapi
more extensible.  As it is now, you can't add another gui library
because there already is one in the dynapi package.  So adding package
support will fix this.  All that is required is a function
addPackage(name), modify the addLibrary to take an extra parameter
packagename, and a small change in the include function.


\\Robert

-- 

Re: [Dynapi-Dev] Some proposals

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

Yes, I think the filenames should be changed too.  The only problem
is when you say dynapi.api.dynlayer.js, the dynapi is never used.
 I think the dynapi should be in the directory structure as well.
 Like: lib2.0/dynapi/api/dynlayer.js.

I posted a zip file in the patches section of Sourceforge that
includes:
- file name structure change
- removed Core name
- hardcoded .onCreate removed/opting for eventlisteners

It also has a lot of other changes, including the recreateall and
addchild fix.

You can get it here: http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=102277&group_id=5757


\\Robert

> Here are  some ideas  I've been thinking about (based on other peoples
> code/input)
>  
> first:  Renaming all files, currently we use  core.xxx.yyy.
> I originally created this not to use sub-folders like this, but to show
> the
> differences between certain objects..  xxx  would be the object group
> and
> yyy would be the name of the object/class/extension.
>  
> The first thing to change would be to replace core with dynapi,  core
> was
> the original name of my own distribution but when my version was copied
> over
> to the original dis. the naming was left this way.. I think this should
> be  dynapi.xxx.yyy
>  
> As example, the webos.com files use the same naming scheme (example:
> webos.ui.component)
> (they probably copied it from us ;-)  So we should really rename all the
> files to dynapi.xxx.yyy
>  
> second: A change in the widgets, to start using eventlisteners and not
> hard-coded methods (I think
> Robert just posted a message mentioning this as well)  If you look at
> the loadpanel from Dan, you'll
> see how this can be achieved, all code and events are handled in the
> widget constructor, making only
> methods and properties available thru prototyping, not the create code..
> example:
>  
> function myWidget() {
>     this.DynLayer=DynLayer    // or other object for sub-class
> inheriting
>     this.DynLayer()
>  
>    var listener=new EventListener(this)
>    listener.oncreate=function(e) {        // this used to be the
> myWidget.prototype.onCreate=function() part
>         // do all stuf to initialise your widget.  
>         // this is actually all the code you would normally put in the
> onCreate function of your widget
>    }
>    this.addEventListener(listener)
>  
>    return this
> }
> myWidget.prototype=new DynLayer()
> myWidget.prototype.methodnames=function() {
> }
>  
>  
> This way we can completely start using eventlisteners, which makes
> everything work in the
> same logicall way... this would require the simple changes to the
> createElement() I posted yesterday
> with the loadPanel() widget.
>  
> I'm planning on converting all my own widgets to this format, because I
> think it makes the widget model
> slightly better (having all create code in the widget constructor) while
> still keeping the simplicity in it.
>  
>  
> Comments please :-)
>  
> 
> 
> Pascal Bestebroer
> pa...@dy... 
> http://www.dynamic-core.net <http://www.dynamic-core.net/>  
> 
>         
>  


-- 

[Dynapi-Dev] Some proposals

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

Here are  some ideas  I've been thinking about (based on other peoples
code/input)

first:  Renaming all files, currently we use  core.xxx.yyy.
I originally created this not to use sub-folders like this, but to show the
differences between certain objects..  xxx  would be the object group and
yyy would be the name of the object/class/extension.

The first thing to change would be to replace core with dynapi,  core was
the original name of my own distribution but when my version was copied over
to the original dis. the naming was left this way.. I think this should be
dynapi.xxx.yyy

As example, the webos.com files use the same naming scheme (example:
webos.ui.component)
(they probably copied it from us ;-)  So we should really rename all the
files to dynapi.xxx.yyy

second:  A change in the widgets, to start using eventlisteners and not
hard-coded methods (I think
Robert just posted a message mentioning this as well)  If you look at the
loadpanel from Dan, you'll
see how this can be achieved, all code and events are handled in the widget
constructor, making only
methods and properties available thru prototyping, not the create code..
example:

function myWidget() {
    this.DynLayer=DynLayer    // or other object for sub-class inheriting
    this.DynLayer()

   var listener=new EventListener(this)
   listener.oncreate=function(e) {        // this used to be the
myWidget.prototype.onCreate=function() part
        // do all stuf to initialise your widget.
        // this is actually all the code you would normally put in the
onCreate function of your widget
   }
   this.addEventListener(listener)

   return this
}
myWidget.prototype=new DynLayer()
myWidget.prototype.methodnames=function() {
}


This way we can completely start using eventlisteners, which makes
everything work in the
same logicall way... this would require the simple changes to the
createElement() I posted yesterday
with the loadPanel() widget.

I'm planning on converting all my own widgets to this format, because I
think it makes the widget model
slightly better (having all create code in the widget constructor) while
still keeping the simplicity in it.


Comments please :-)

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

[Dynapi-Dev] deleteAllChildren and deleteChild

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

It seems like deleteAllChildren is not very consistent with
deleteChild.

Shouldn't deleteAllChildren be like this:

DynLayer.prototype.deleteAllChildren=function() {
  for (var i=0;i<this.children.length;i++)
    this.deleteChild(this.children[i])
}

The only problem is that is that it would take forever because each
call would be nested in a for loop in the deleteChild method.  Maybe a
childrenID array?

Another idea for the .all and .allID arrays
is to store the .all index of the object in the .allID array for the
object.  Then we could remove
the numerous for loops looking for it and the for loops that delete it
in the .all array.  Then we could say this.all[this.allID[someid].index].


\\Robert

-- 

Re: [Dynapi-Dev] Updated dynlayer and dyndocument

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

> Hey I just threw this into my files fired up Netscape opened up the gui.menulist, and
> resized away...Yeah!!! the layers are recreated....but if I keep doing over and over,
> the redraw of the layers slow down, until at about the 10th time it stops redrawing,
> is the recreateall, reusing the previous layers or creating new ones? if it is
> creating new ones could it be the old ones are not being killed off and hence the
> slowdown and freeze as you clog the browser with layers
> 
> If you reload or move to a new page and back everything is fine so hopefully, for now
> users won't resize 10 times while on the same page :-)

Recreateall does actually recreate the layers in Netscape.  And the
function that is used, createElement, could probaly use some more optimization.

A lot of it could just be a Netscape memory allocation thing, too.  But, I
see several places that the dynlayer can be fixed so that the creation
will speed up.  Hopefully I fix some of these early next week and post
them.  I haven't really tested my update to much, but hopefully
someone will find some optimizations as well.

\\Robert

-- 

Re: [Dynapi-Dev] Updated dynlayer and dyndocument

[Rob R. <ro...@ma...>]

Robert Rainwater wrote:

> I've updated the dynlayer and dyndocument so that the recreateall will
> actually work.

Hey I just threw this into my files fired up Netscape opened up the gui.menulist, and
resized away...Yeah!!! the layers are recreated....but if I keep doing over and over,
the redraw of the layers slow down, until at about the 10th time it stops redrawing,
is the recreateall, reusing the previous layers or creating new ones? if it is
creating new ones could it be the old ones are not being killed off and hence the
slowdown and freeze as you clog the browser with layers

If you reload or move to a new page and back everything is fine so hopefully, for now
users won't resize 10 times while on the same page :-)

thanks,

Rob Romanek

[Dynapi-Dev] Updated dynlayer and dyndocument

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

I've updated the dynlayer and dyndocument so that the recreateall will
actually work.  The biggest pain was adding children of children to
the all array in the addChild method.  So I added a method addChildID
that should fix the problem.  When a dynlayer thats knows its dyndoc
or a dyndocument itself calls addchild, then that child and all of its
children are added to the .all and .allID arrays.

I've attached my dynlayer and dyndocument files.  Please let me know
of any bugs/improvements because it hasn't been fully tested yet.

Also, the method calls like oncreate that are hard coded into the
dynlayer need to be removed.  Like:
if (this.onCreate) { this.onCreate() }   //<-

The only problem is that they are used in some of the widgets.  So if
we are going to remove these, everyone should make sure their widgets
use the eventlisteners instead.

Also, could someone tell me the purpose of the .all array?  I know we
need the allID array, but the all array I just don't understand.


\\Robert

-- 

[Dynapi-Dev] LoadPanel

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

<html>=0A=
<head>=0A=
<title>DynAPI Examples - LoadPanel</title>=0A=
<script language=3D"Javascript" src=3D"../js/dynapi.js"></script>=0A=
<script language=3D"Javascript">=0A=
=0A=
DynAPI.setLibraryPath('../js/lib2.0/')=0A=
=0A=
DynAPI.include('core.api.dynlayer.js')=0A=
DynAPI.include('core.api.browser.js')=0A=
DynAPI.include('core.api.dyndocument.js')=0A=
DynAPI.include('core.ext.loadpanel.js')=0A=
DynAPI.include('core.api.events.js')=0A=
=0A=
=0A=
DynAPI.onLoad=3Dfunction() {=0A=
=0A=
	lp =3D new LoadPanel()=0A=
//	lp.useILayer(true)=0A=
	=0A=
	lp.setSize(250,50) // height will be overwritten by default=0A=
	lp.moveTo(200,100)=0A=
	lp.setBgColor('yellow')=0A=
	=0A=
	counter =3D 0=0A=
	=0A=
	var el =3D new EventListener()=0A=
	el.onload =3D function(e) {=0A=
		status =3D 'got load event '+ counter++=0A=
	}=0A=
	lp.addEventListener(el)=0A=
	=0A=
	DynAPI.document.addChild(lp)	=0A=
}=0A=
=0A=
//-->=0A=
</script>=0A=
</head>=0A=
<body bgcolor=3D"#ffffff">=0A=
=0A=
<p><a href=3D"javascript:lp.useILayer(true)">use ILayer</a> Netscape=0A=
<br><a href=3D"javascript:lp.useILayer(false)">do not use ILayer</a> =
Netscape (default)=0A=
=0A=
<p><a href=3D"javascript:lp.useIFrame(true)">use IFrame</a> IE (default)=0A=
<br><a href=3D"javascript:lp.useIFrame(false)">do not use IFrame</a> IE=0A=
=0A=
<p>Load Files:=0A=
<br><a href=3D"javascript:lp.setURL('loadpanel-file1.html')">file 1</a>=0A=
<br><a href=3D"javascript:lp.setURL('loadpanel-file2.html')">file 2</a>=0A=
=0A=
<p>Set Width:=0A=
<br><a href=3D"javascript:lp.setWidth(150)">150</a>=0A=
<br><a href=3D"javascript:lp.setWidth(250)">250</a>=0A=
=0A=
<p><a href=3D"javascript:lp.clearFile()">Clear</a>=0A=
=0A=
</body>=0A=
</html>=0A=

RE: [Dynapi-Dev] Referencing forms in nested layers

[Pascal B. <pb...@oi...>]

use the layer's   .doc property to reference the document of the layer:

myLayer.doc.formname.formitem.value='whatever'

or for images:

myLayer.doc.images[imagename].src='mygif.jpg'


Pascal Bestebroer
pb...@oi...
http://www.oibv.com
-----Oorspronkelijk bericht-----
Van: dyn...@li...
[mailto:dyn...@li...]Namens Samuel, Michael M
Verzonden: vrijdag 3 november 2000 8:34
Aan: 'Dyn...@li...'
Onderwerp: [Dynapi-Dev] Referencing forms in nested layers


I'm new to the mailing lists here - so I beg your forgiveness if this isn't
the appropriate list to send this to! :)
I'm working on a page with multiple layers essentially creating a
windows-esque dialogue interface. I've got forms referenced on several of
the layers, and what I'm trying to do is create a new Option on one layer
with a select box. What is the syntax for referencing the forms on a layer
without traversing the document tree as with netscape?
Thanks for the support!
Mike

[Dynapi-Dev] Inline Layers - Events Bug in NS Using Double-Click

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

When using inline layers, I am able to capture all mouse events except
double-click in Netscape.  In IE, it works fine.  Double-click is also
working for regular dynlayers.  So, I am assuming the problem with
double-click in NS may be in the inline.js.

Any ideas?


\\Robert

-- 

[Dynapi-Dev] Core DynAPI2 - Loading html files into DynLayer's

[Liam C. <met...@ma...>]

First a big 'thankyou' to everyone who has contributed to this excellent
tool.

I am a UK based Mac OS9 and X based professional web-developer, and if I can
be of any help in QAing code for this platform please feel free to ask.

I'm currently porting a site using a heavily customised (messy) DynAPI1, to
DynAPI2, but having not built the original have some questions I cant seem
to answer:

1) Possibly a newbie (to version 2) question, but I have consulted the docs,
archives and examples to find a step-by-step answer:

I'd like to maintain this site with separate html files that are loaded into
DynLayers when I create them, how do I achieve this? Does the DynAPI2 get
around using an IFRAME buffer in IE?

2) Similarly my experience has led me to rely on external css for the
configuration of layers. Is there any way to apply specified 'class' tags to
DynLayers at creation time? Or should I convert this to use an external JS
based config file with variables?

3) Ambitiously I would like to place Flash movies (and other Plugin media)
on DynLayers and have them dragable. This is currently working with DynAPI1,
and  works fine in Netscape with the Core distribution, but IE 5 Mac leaves
the plugin area behind (havnet tried IE 4+ PC yet). Has anyone any
experience ideas about this problem?
(I am wisely ignoring IE 4.5 Mac)

Finally I have some feedback on the Dynacore DynAPI2 distribution
(unofficial one):

1) The benchmarks work without a hitch in Netscape 4.74 and 4.76 (all Mac)
2) In Netscape 4.08 Mac the benchmarks run without errors until B4 but no
layers are ever shown (weird), all alerts etc report back faithfully.
3) In IE 5 Mac anything involving hiding or deleting a Dynlayer results in a
'permission denied' alert (B2 line232, B3 line 308), and the eventlistener
(B4) works but can be erratic.

Happy to give further details if these haven't been noted before.

TIA

Liam Clancy

-- 
"Everything in moderation ... including moderation"

pgp on request

[Dynapi-Dev] Referencing forms in nested layers

[Samuel, M. M <Sam...@ed...>]

I'm new to the mailing lists here - so I beg your forgiveness if this isn't the
appropriate list to send this to! :)

I'm working on a page with multiple layers essentially creating a windows-esque
dialogue interface. I've got forms referenced on several of the layers, and what
I'm trying to do is create a new Option on one layer with a select box. What is
the syntax for referencing the forms on a layer without traversing the document
tree as with netscape?

Thanks for the support!

Mike

Re: [Dynapi-Dev] RE: Still having image animation problems (event catching)

[Rob R. <ro...@ma...>]

I build buttons in similar way the way I trap the events is to put up a mask
layer inside the widget that is basically transparent but sits on top of all
the other layers. I then use this to trap mouse events and handle them at the
level of the widget. If you want to have the cursor change by using css then
the only way I've worked out to do that is to put a transparent 1 pixel image
in the mask layer and scale it to size, then use a <span> tag around it for
the cursor handling. It may not be orthodox but it works.

HTH,

Rob

".:: OCB ::." wrote:

> Hi,
>
> Well, in regards my rollOver animation problem..
>
> I sorted out my IE 'always reloading the images' problem by setting each
> image in the animation within it's own DynLayer(). Now I seem to have the
> dreaded 'can't catch mouseOver events' IE problem.
>
> Again, any solutions to this headache ?
>
> I have tried to catch events on the main Widgit and not on the image
> DynLayers it encapsulates. I have even tried to use setHTML("    ") on the
> widgit (dam, how do you spell widgit ? widget ? wigit ?) to try to have
> something to catch the events 'on' but still, in IE I can't seem to catch
> mouseOver events at all (onClick events work properly though).
>
> Thanks again... OCB
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
>
> Share information about yourself, create your own public profile at
> http://profiles.msn.com.
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev