dynapi-notify — Read-only list for tracker notifications (Bugs, Patches, Feature Requests, etc.)

[DynAPI-notify] [ dynapi-Bugs-568447 ] Dynlayer doesn'n cover comboboxes

[SourceForge.net <no...@so...>]

Bugs item #568447, was opened at 2002-06-13 05:53
Message generated for change (Settings changed) made by warp9pnt9
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105757&aid=568447&group_id=5757

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: DynAPI 2 API
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Verena Lampe (vlampe)
>Assigned to: L W (warp9pnt9)
Summary: Dynlayer doesn'n cover comboboxes

Initial Comment:
When I generate a dynlayer it covers all form elements 
beside <select><option>...

Example:
see attached file

----------------------------------------------------------------------

Comment By: Doug Melvin (doug_melvin)
Date: 2005-07-29 15:33

Message:
Logged In: YES 
user_id=184788

***Close me*** Or give me admin access back pls and I'll
close it.


----------------------------------------------------------------------

Comment By: Verena Lampe (vlampe)
Date: 2002-06-17 03:11

Message:
Logged In: YES 
user_id=232208

I found the reason of the problem myself - it isn't the Dynapi 
library but the browser (IE 5.0). It's impossible to cover a 
select-box with a layer neither in IE 5.0 nor in NS 4.

vlampe

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-13 11:11

Message:
Logged In: NO 

PLEASE!! when posting bug reports you MUST include what 
browser you where using (including version) as well as what 
platform (Windows, Mac, Linux, Solaris).

It is known that Netscape 4.x has a problem with form 
elements haveing a z-index of infinity. This is a problem with 
Netscape, and not with DynLayers. If your problem is occuring 
in a browser other than Netscape 4.x then please advise.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105757&aid=568447&group_id=5757

[DynAPI-notify] [ dynapi-Bugs-1179797 ] Memory Leak when using Frames

[SourceForge.net <no...@so...>]

Bugs item #1179797, was opened at 2005-04-09 11:46
Message generated for change (Comment added) made by warp9pnt9
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1179797&group_id=5757

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: DynAPI 3 API
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fausto (faustogomes)
Assigned to: Andrew Gillett (agillett)
Summary: Memory Leak when using Frames

Initial Comment:
When using frames DynAPI will leak memory at about 
500kb per F5 (Refresh) on IE 6 sp1.

It will not leak when no frames are used. This version 
has the patch http://sourceforge.net/tracker/index.php?
func=detail&aid=787137&group_id=5757&atid=105757
implemented already.

----------------------------------------------------------------------

>Comment By: L W (warp9pnt9)
Date: 2005-08-03 07:55

Message:
Logged In: YES 
user_id=706287

To the original poster, please specify more information. 
Upload an example in a single zip of the main html and each
frame's html.  Clearly specify how DynAPI is being used
during the observed problem.  Only then can we hope to
determine the problem.

It is impossible for us to fix a problem if we can't quickly
reproduce and observ it ourselves.  There are too many
variables to make wild guesses here.  We could spend weeks
and not hit the same exact combination of circumstances to
cause the problem you report.

If there's no response by next release I'll close this
because of insufficiant data.  If the issue arises again
with precise information supplied, it can of course be
reopened and revisited.


----------------------------------------------------------------------

Comment By: Doug Melvin (doug_melvin)
Date: 2005-07-29 15:19

Message:
Logged In: YES 
user_id=184788

Possibly related to bug 787137:	Memory leak in
DynElement.deleteChild()

Apply patch indicated in bug #787137 and test this one again

----------------------------------------------------------------------

Comment By: Andrew Gillett (agillett)
Date: 2005-04-22 07:24

Message:
Logged In: YES 
user_id=134108

A few questions:
Which version of DynAPI - 3.0beta1, one of the snapshots, or
the current CVS version?
When you say "When using frames", I take it you mean you
have a page with multiple frames, one of which is displaying
a page that uses DynAPI?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1179797&group_id=5757

[DynAPI-notify] [ dynapi-Bugs-787137 ] Memory leak in DynElement.deleteChild()

[SourceForge.net <no...@so...>]

Bugs item #787137, was opened at 2003-08-11 23:36
Message generated for change (Comment added) made by warp9pnt9
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105757&aid=787137&group_id=5757

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: DynAPI 3 API
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Gillett (agillett)
Assigned to: L W (warp9pnt9)
Summary: Memory leak in DynElement.deleteChild()

Initial Comment:
The DynElement.deleteChild() function is implemented 
thus:

p.deleteChild = function(c) {
	c.removeFromParent();
   	c._delete();
};

Although the _delete() function is documented in 
quickref.dynelement.html, it is not implemented 
_anywhere_ in the DynAPI source code, except for 
being set to dynapi.functions.Null in event.js.

If you have a page that repeatedly adds and removes 
DynElements, it will leak memory.  If you replace the call
to _delete() with a call to _destroy(), the memory leak 
goes away:

p.deleteChild = function(c) {
	c.removeFromParent();
   	c._destroy();
};


----------------------------------------------------------------------

>Comment By: L W (warp9pnt9)
Date: 2005-08-03 07:24

Message:
Logged In: YES 
user_id=706287

The memory still leaks in IE6, although much slower than in
FireFox.

----------------------------------------------------------------------

Comment By: L W (warp9pnt9)
Date: 2005-08-03 07:20

Message:
Logged In: YES 
user_id=706287

The change has been applied in the dynapi-3.0.0-beta2
release.  However I still get a fair amount of memory
leaking in FireFox 1.0.6 with the provided bug script.  Can
someone else verify in other browsers?  Either there's
another memory leak in the api, or the test case code, or
it's a Mozilla problem.

----------------------------------------------------------------------

Comment By: Doug Melvin (doug_melvin)
Date: 2005-07-29 15:17

Message:
Logged In: YES 
user_id=184788

Confirmed: _delete() is depecriated code.
The correct call is _destroy()

Please implement in cvs copy and and close this bug.

Thanks (I'll check if i have cvs write access this evening)

The change:
Line 159 of event.js:
change from: c._delete();
to: c._destroy();

----------------------------------------------------------------------

Comment By: Raymond Irving (xwisdom)
Date: 2003-08-14 20:15

Message:
Logged In: YES 
user_id=696242

I believe the lastest snapshot should have fixed this problem. 
I did add _destroy() to the deleteChild() function and made 
some other changes that fixed the problem. 

Keep up the good work.


----------------------------------------------------------------------

Comment By: Andrew Gillett (agillett)
Date: 2003-08-14 19:48

Message:
Logged In: YES 
user_id=134108

Hmm, we could have: remove, delete, destroy and dispose.

> I see what's happening. IMO deleteChild() and removeChild
> means the same thing, correct?
No. To my way of thinking, 'delete' should be like the C++ 
keyword - once deleted an object no longer exists.  And why 
have both deleteChild and removeChild if they do the same 
thing?

IMO we should just add the _destroy() function to deleteChild 
and update the documentation accordingly.


----------------------------------------------------------------------

Comment By: Raymond Irving (xwisdom)
Date: 2003-08-14 09:02

Message:
Logged In: YES 
user_id=696242


Thanks for the feedback

Ok. Will keep the delete functions them _destroy() the layers 
as well.


----------------------------------------------------------------------

Comment By: L W (warp9pnt9)
Date: 2003-08-14 08:30

Message:
Logged In: YES 
user_id=706287

My view on the matter.

I think the naming convention would be clearer if the
function that removes children from parents was called
removeChild / removeFromParent, but not destroying the
layer.  I think this is how it works now.  I think the
function that removes the child from the parent AND destroys
the layer should be called deleteChild / deleteFromParent or
maybe destroyChild / destroyFromParent.  I think it's
confusing to add a new name "dispose" when it doesn't
intuitively correspond to an underlying "dispose" function.
 It's a little vague.

----------------------------------------------------------------------

Comment By: Raymond Irving (xwisdom)
Date: 2003-08-13 22:37

Message:
Logged In: YES 
user_id=696242


I see what's happening. IMO deleteChild() and removeChild 
means the same thing, correct? 

When a child layer is removed from the parent it's actually 
deleted from the parent, correct?  The layer is not completly 
destroyed as a reference to it still exists within DynObject.all 
collection. 

Calling _destroy() during a deleteChild() function will not only 
delete the child from its parent but it will also dispose of the 
child object.

I think we should change deleteChild/AllChildren/etc to 
disposeChild/AllChildren/etc wihich will clearly define what is 
been done to the object. The dispose functions will complete 
remove and destroy the object.

Are we all in agreement with changing delete to dispose? Or 
should we add the _destroy() function to deleteChild and 
keep the delete functions?  

(Note: If we keep the delete functions we'll have to 
document that it will completely destroy and remove the layer 
from the system.)



----------------------------------------------------------------------

Comment By: Andrew Gillett (agillett)
Date: 2003-08-13 20:31

Message:
Logged In: YES 
user_id=134108

> Are you using the lastest snapshot?
Yes, I check out the code directly from CVS.
> What browsers are experiencing this memory leak?
IE6 & Mozilla1.4, but that is not really relevant.

On 29/07/2003 12:26 AM (my time), in response to my post 
about a bug in deleteAllChildren(), you wrote:
>To fix the memory and layer problem use the following:
>
>p.deleteAllChildren = function() {
>	var c,l = this.children.length;
>	for(var i=0;i<l;i++) {
>		c=this.children[i];
>		if(c) {
>			c._destroy();
>			c._created = c.isChild = false;
>		};
>		delete this.children[i];
>	}
>	this.children.length = 0;
>};
>
This fix worked perfectly. The _destroy() method is called on 
each child of the layer.

However this is not what was put into CVS.  In the current 
version of event.js, deleteAllChildren() calls deleteFromParent
() which calls deleteChild() which calls _delete() instead of 
_destroy().

It is the call to _delete() that I have a problem with.  There 
is simply no such function.  In line 184 of event.js there is:

... = p._delete = p._destroy = dynapi.functions.Null;

but nowhere else in the entire source tree is _delete() 
defined.


Try the attached example.  On my Windows XP system, IE 
grows by about 6MB each time the "Memory Leak" button is 
pressed.  But if I replace the call to _delete() with a call to 
_destroy() in the deleteChild function, then IE doesn't leak at 
all.


----------------------------------------------------------------------

Comment By: Raymond Irving (xwisdom)
Date: 2003-08-13 09:53

Message:
Logged In: YES 
user_id=696242

Are you using the lastest snapshot?

What browsers are experiencing this memory leak?

You can get the lastest snapshot here:
http://dynapi.sourceforge.net/snapshot/?N=D


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105757&aid=787137&group_id=5757

[DynAPI-notify] [ dynapi-Bugs-787137 ] Memory leak in DynElement.deleteChild()

[SourceForge.net <no...@so...>]

Bugs item #787137, was opened at 2003-08-11 23:36
Message generated for change (Comment added) made by warp9pnt9
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105757&aid=787137&group_id=5757

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: DynAPI 3 API
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Gillett (agillett)
>Assigned to: L W (warp9pnt9)
Summary: Memory leak in DynElement.deleteChild()

Initial Comment:
The DynElement.deleteChild() function is implemented 
thus:

p.deleteChild = function(c) {
	c.removeFromParent();
   	c._delete();
};

Although the _delete() function is documented in 
quickref.dynelement.html, it is not implemented 
_anywhere_ in the DynAPI source code, except for 
being set to dynapi.functions.Null in event.js.

If you have a page that repeatedly adds and removes 
DynElements, it will leak memory.  If you replace the call
to _delete() with a call to _destroy(), the memory leak 
goes away:

p.deleteChild = function(c) {
	c.removeFromParent();
   	c._destroy();
};


----------------------------------------------------------------------

>Comment By: L W (warp9pnt9)
Date: 2005-08-03 07:20

Message:
Logged In: YES 
user_id=706287

The change has been applied in the dynapi-3.0.0-beta2
release.  However I still get a fair amount of memory
leaking in FireFox 1.0.6 with the provided bug script.  Can
someone else verify in other browsers?  Either there's
another memory leak in the api, or the test case code, or
it's a Mozilla problem.

----------------------------------------------------------------------

Comment By: Doug Melvin (doug_melvin)
Date: 2005-07-29 15:17

Message:
Logged In: YES 
user_id=184788

Confirmed: _delete() is depecriated code.
The correct call is _destroy()

Please implement in cvs copy and and close this bug.

Thanks (I'll check if i have cvs write access this evening)

The change:
Line 159 of event.js:
change from: c._delete();
to: c._destroy();

----------------------------------------------------------------------

Comment By: Raymond Irving (xwisdom)
Date: 2003-08-14 20:15

Message:
Logged In: YES 
user_id=696242

I believe the lastest snapshot should have fixed this problem. 
I did add _destroy() to the deleteChild() function and made 
some other changes that fixed the problem. 

Keep up the good work.


----------------------------------------------------------------------

Comment By: Andrew Gillett (agillett)
Date: 2003-08-14 19:48

Message:
Logged In: YES 
user_id=134108

Hmm, we could have: remove, delete, destroy and dispose.

> I see what's happening. IMO deleteChild() and removeChild
> means the same thing, correct?
No. To my way of thinking, 'delete' should be like the C++ 
keyword - once deleted an object no longer exists.  And why 
have both deleteChild and removeChild if they do the same 
thing?

IMO we should just add the _destroy() function to deleteChild 
and update the documentation accordingly.


----------------------------------------------------------------------

Comment By: Raymond Irving (xwisdom)
Date: 2003-08-14 09:02

Message:
Logged In: YES 
user_id=696242


Thanks for the feedback

Ok. Will keep the delete functions them _destroy() the layers 
as well.


----------------------------------------------------------------------

Comment By: L W (warp9pnt9)
Date: 2003-08-14 08:30

Message:
Logged In: YES 
user_id=706287

My view on the matter.

I think the naming convention would be clearer if the
function that removes children from parents was called
removeChild / removeFromParent, but not destroying the
layer.  I think this is how it works now.  I think the
function that removes the child from the parent AND destroys
the layer should be called deleteChild / deleteFromParent or
maybe destroyChild / destroyFromParent.  I think it's
confusing to add a new name "dispose" when it doesn't
intuitively correspond to an underlying "dispose" function.
 It's a little vague.

----------------------------------------------------------------------

Comment By: Raymond Irving (xwisdom)
Date: 2003-08-13 22:37

Message:
Logged In: YES 
user_id=696242


I see what's happening. IMO deleteChild() and removeChild 
means the same thing, correct? 

When a child layer is removed from the parent it's actually 
deleted from the parent, correct?  The layer is not completly 
destroyed as a reference to it still exists within DynObject.all 
collection. 

Calling _destroy() during a deleteChild() function will not only 
delete the child from its parent but it will also dispose of the 
child object.

I think we should change deleteChild/AllChildren/etc to 
disposeChild/AllChildren/etc wihich will clearly define what is 
been done to the object. The dispose functions will complete 
remove and destroy the object.

Are we all in agreement with changing delete to dispose? Or 
should we add the _destroy() function to deleteChild and 
keep the delete functions?  

(Note: If we keep the delete functions we'll have to 
document that it will completely destroy and remove the layer 
from the system.)



----------------------------------------------------------------------

Comment By: Andrew Gillett (agillett)
Date: 2003-08-13 20:31

Message:
Logged In: YES 
user_id=134108

> Are you using the lastest snapshot?
Yes, I check out the code directly from CVS.
> What browsers are experiencing this memory leak?
IE6 & Mozilla1.4, but that is not really relevant.

On 29/07/2003 12:26 AM (my time), in response to my post 
about a bug in deleteAllChildren(), you wrote:
>To fix the memory and layer problem use the following:
>
>p.deleteAllChildren = function() {
>	var c,l = this.children.length;
>	for(var i=0;i<l;i++) {
>		c=this.children[i];
>		if(c) {
>			c._destroy();
>			c._created = c.isChild = false;
>		};
>		delete this.children[i];
>	}
>	this.children.length = 0;
>};
>
This fix worked perfectly. The _destroy() method is called on 
each child of the layer.

However this is not what was put into CVS.  In the current 
version of event.js, deleteAllChildren() calls deleteFromParent
() which calls deleteChild() which calls _delete() instead of 
_destroy().

It is the call to _delete() that I have a problem with.  There 
is simply no such function.  In line 184 of event.js there is:

... = p._delete = p._destroy = dynapi.functions.Null;

but nowhere else in the entire source tree is _delete() 
defined.


Try the attached example.  On my Windows XP system, IE 
grows by about 6MB each time the "Memory Leak" button is 
pressed.  But if I replace the call to _delete() with a call to 
_destroy() in the deleteChild function, then IE doesn't leak at 
all.


----------------------------------------------------------------------

Comment By: Raymond Irving (xwisdom)
Date: 2003-08-13 09:53

Message:
Logged In: YES 
user_id=696242

Are you using the lastest snapshot?

What browsers are experiencing this memory leak?

You can get the lastest snapshot here:
http://dynapi.sourceforge.net/snapshot/?N=D


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105757&aid=787137&group_id=5757

[DynAPI-notify] [ dynapi-Bugs-769283 ] Event error

[SourceForge.net <no...@so...>]

Bugs item #769283, was opened at 2003-07-10 12:46
Message generated for change (Comment added) made by doug_melvin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105757&aid=769283&group_id=5757

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: DynAPI 3 API
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel Tiru (tiru)
Assigned to: Nobody/Anonymous (nobody)
Summary: Event error

Initial Comment:
Hi!

I have a HTML button and a onclick event assigned to 
that one.

parent.hb = new parent.HTMLButton
('submit','Login','Login');
parent.hb.addEventListener({
	onclick:function(e){
		var o=e.getSource();
		parent.PostData
('frmLogin','response.asp');
	}
});

When i click on the button one time, it works fine, 
however when i click another time, it returns: 
Error: Can't execute code from a freed script
Line: 77 in event.js
The line in event js looks like this:
if (this._listeners[i]["on"+type]) this._listeners[i]
["on"+type](e,args);
And my debugger marks this part:
this._listeners[i]["on"+type](e,args)

The script it calls works fine, i have tried it several times 
without a HTMLButton, with just an ordinary button.

Hope this info helps out in solving this.
Regards
Daniel

----------------------------------------------------------------------

Comment By: Doug Melvin (doug_melvin)
Date: 2005-07-29 12:41

Message:
Logged In: YES 
user_id=184788

how about using the browser's namespace?
I.E. top. instead of parent. could be the parent is being
reinitialized on reload which is loosing all yer code.

top.whatever="blagme" places a vaiable in the top-level
window which swill not be erase when reloading the iframe
inside that window

----------------------------------------------------------------------

Comment By: Raymond Irving (xwisdom)
Date: 2003-07-11 07:28

Message:
Logged In: YES 
user_id=696242


This has to do with your code:

onclick:function(e){ 
var o=e.getSource(); 
parent.PostData ('frmLogin','response.asp'); 

This section of the code was created inside the ioelement's 
Iframe object. Whenever you send another post it will clear 
the content of the IFrame thus giving the error. The 
downloaded js code was not created within the scope of the 
main document but within the scope of the iframe object

I've seen it before and I'm thinking of a way to resolve it.

--
Raymond Irving

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105757&aid=769283&group_id=5757

[DynAPI-notify] [ dynapi-Bugs-870414 ] Check *before* setting the window.onload-function

[SourceForge.net <no...@so...>]

Bugs item #870414, was opened at 2004-01-04 08:19
Message generated for change (Comment added) made by doug_melvin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105757&aid=870414&group_id=5757

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: DynAPI 3 API
Group: Verified
Status: Open
Resolution: None
Priority: 5
Submitted By: Sam Blum (bs_php)
Assigned to: Nobody/Anonymous (nobody)
Summary: Check *before* setting the window.onload-function

Initial Comment:
There are cases where other 3rd party script are loaded 
that *also* overload the window.onload-function.

In dynAPI should check that the window.onload-
function is 'free'.

Correction follows:
=============
in dynapi.js near line 99 
--------------- replace this -----------------
f.onload = function() {

--------------- with this -----------------
// Befor setting the window.onload-function we must 
check if it's not already in use (by some other 3rd party 
script loaded). 
// So we backup the function to call it.  
var onloadBak = (typeof(f.onload)=='function') ? 
f.onload : false;
f.onload = function() {
    if (onloadBak) onloadBak();

modified  dynapi.js  is attached






----------------------------------------------------------------------

Comment By: Doug Melvin (doug_melvin)
Date: 2005-07-29 12:37

Message:
Logged In: YES 
user_id=184788

very good point.. let's do that shall we?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105757&aid=870414&group_id=5757

[DynAPI-notify] [ dynapi-Bugs-567293 ] LoadPanel error in IE6(line 188)

[SourceForge.net <no...@so...>]

Bugs item #567293, was opened at 2002-06-11 00:24
Message generated for change (Comment added) made by doug_melvin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105757&aid=567293&group_id=5757

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: DynAPI 2 Browser-Specific
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Igor Tsigelnik (tsigelnik)
Assigned to: Nobody/Anonymous (nobody)
Summary: LoadPanel error in IE6(line 188)

Initial Comment:
(line 188 Object required)
Error only in IE6 when try to load file in LoadPanel
To resolve problem I change line 16
from:
this.isIFrame=!(is.ie5 && is.platform=='win32');
to:	
this.isIFrame=!((is.ie6 || is.ie5) && 
is.platform=='win32');




----------------------------------------------------------------------

Comment By: Doug Melvin (doug_melvin)
Date: 2005-07-29 12:35

Message:
Logged In: YES 
user_id=184788

how about this.isIFrame=!((is.ie && !is.ie4) &&
is.platform=='win32');

this will effect future versions such as IE 7 or 8 or 22 :-P

Holey crap.. just realised this is for DynAPI 2.. LOL.. is
anyone actually patching 2.x for distrobution?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105757&aid=567293&group_id=5757

[DynAPI-notify] [ dynapi-Bugs-568447 ] Dynlayer doesn'n cover comboboxes

[SourceForge.net <no...@so...>]

Bugs item #568447, was opened at 2002-06-13 02:53
Message generated for change (Comment added) made by doug_melvin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105757&aid=568447&group_id=5757

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: DynAPI 2 API
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Verena Lampe (vlampe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Dynlayer doesn'n cover comboboxes

Initial Comment:
When I generate a dynlayer it covers all form elements 
beside <select><option>...

Example:
see attached file

----------------------------------------------------------------------

Comment By: Doug Melvin (doug_melvin)
Date: 2005-07-29 12:33

Message:
Logged In: YES 
user_id=184788

***Close me*** Or give me admin access back pls and I'll
close it.


----------------------------------------------------------------------

Comment By: Verena Lampe (vlampe)
Date: 2002-06-17 00:11

Message:
Logged In: YES 
user_id=232208

I found the reason of the problem myself - it isn't the Dynapi 
library but the browser (IE 5.0). It's impossible to cover a 
select-box with a layer neither in IE 5.0 nor in NS 4.

vlampe

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-13 08:11

Message:
Logged In: NO 

PLEASE!! when posting bug reports you MUST include what 
browser you where using (including version) as well as what 
platform (Windows, Mac, Linux, Solaris).

It is known that Netscape 4.x has a problem with form 
elements haveing a z-index of infinity. This is a problem with 
Netscape, and not with DynLayers. If your problem is occuring 
in a browser other than Netscape 4.x then please advise.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105757&aid=568447&group_id=5757

[DynAPI-notify] [ dynapi-Bugs-607503 ] Exception occured when using IE 6.0

[SourceForge.net <no...@so...>]

Bugs item #607503, was opened at 2002-09-10 13:41
Message generated for change (Comment added) made by doug_melvin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105757&aid=607503&group_id=5757

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: DynAPI 2 API
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Junn Salvatin (ragerunner)
Assigned to: Nobody/Anonymous (nobody)
Summary: Exception occured when using IE 6.0

Initial Comment:
We getting an exception when we switch to IE 6.0 from IE 
5.5.

Here's the error message:
DynAPI reported an error
Error in project: 'http://..../...../desktop.jsp
Line number: 185

Message: Exception occurred.

I was able to track this message in Dynapi.js in the function 
call:
DynAPIObject.prototype.errorHandler = function (msg, url, 
lno) {
	if (!this.loaded || !this.errorHandling) return false;
	if (is.ie) {
		lno-=1;
		alert("DynAPI reported an 
error\n\nError in project: '" + url + "'.\nLine number: " + lno 
+ ".\n\nMessage: " + msg);
	} else if (is.ns4) {
		alert("DynAPI reported an 
error\n\nError in file: '" + url + "'.\nLine number: " + lno 
+ ".\n\nMessage: " + msg);
	} else return false;
	return this.returnErrors;
}

I can't determine wherethe exception is occuring in the 
desktop.jsp.
The line number seems  to be misleading.

Can any one help us?

Can some one tell us how to find out which version of 
Dynapi we're using.  We inherited the code  from a vendor 
and we don't know which version of Dynapi we're using.

Thanks.... for your support....



----------------------------------------------------------------------

Comment By: Doug Melvin (doug_melvin)
Date: 2005-07-29 12:30

Message:
Logged In: YES 
user_id=184788

Can someone please remind us how to turn off the dynapi
error handling?

I expect it will be a lot easier for them to debug if they
could get the  "raw" error.

Junn: if the root of your dynapi folder looks something like
this:
/dynapi/
	/lib/
	dynapi.js

then you are using an older version in which case I will
need more info to tell you what version you are using.

DynAPI 3+ has a structure more like this:
/src/
	/api/
	/ext/
	/fx/
	/gui/
	/util/
	dynapi.js
	version.xml	

with version.xml containing the exact version.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105757&aid=607503&group_id=5757

[DynAPI-notify] [ dynapi-Bugs-1179797 ] Memory Leak when using Frames

[SourceForge.net <no...@so...>]

Bugs item #1179797, was opened at 2005-04-09 08:46
Message generated for change (Comment added) made by doug_melvin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1179797&group_id=5757

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: DynAPI 3 API
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fausto (faustogomes)
Assigned to: Andrew Gillett (agillett)
Summary: Memory Leak when using Frames

Initial Comment:
When using frames DynAPI will leak memory at about 
500kb per F5 (Refresh) on IE 6 sp1.

It will not leak when no frames are used. This version 
has the patch http://sourceforge.net/tracker/index.php?
func=detail&aid=787137&group_id=5757&atid=105757
implemented already.

----------------------------------------------------------------------

Comment By: Doug Melvin (doug_melvin)
Date: 2005-07-29 12:19

Message:
Logged In: YES 
user_id=184788

Possibly related to bug 787137:	Memory leak in
DynElement.deleteChild()

Apply patch indicated in bug #787137 and test this one again

----------------------------------------------------------------------

Comment By: Andrew Gillett (agillett)
Date: 2005-04-22 04:24

Message:
Logged In: YES 
user_id=134108

A few questions:
Which version of DynAPI - 3.0beta1, one of the snapshots, or
the current CVS version?
When you say "When using frames", I take it you mean you
have a page with multiple frames, one of which is displaying
a page that uses DynAPI?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105757&aid=1179797&group_id=5757

[DynAPI-notify] [ dynapi-Bugs-787137 ] Memory leak in DynElement.deleteChild()

[SourceForge.net <no...@so...>]

Bugs item #787137, was opened at 2003-08-11 20:36
Message generated for change (Comment added) made by doug_melvin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105757&aid=787137&group_id=5757

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: DynAPI 3 API
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Gillett (agillett)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory leak in DynElement.deleteChild()

Initial Comment:
The DynElement.deleteChild() function is implemented 
thus:

p.deleteChild = function(c) {
	c.removeFromParent();
   	c._delete();
};

Although the _delete() function is documented in 
quickref.dynelement.html, it is not implemented 
_anywhere_ in the DynAPI source code, except for 
being set to dynapi.functions.Null in event.js.

If you have a page that repeatedly adds and removes 
DynElements, it will leak memory.  If you replace the call
to _delete() with a call to _destroy(), the memory leak 
goes away:

p.deleteChild = function(c) {
	c.removeFromParent();
   	c._destroy();
};


----------------------------------------------------------------------

Comment By: Doug Melvin (doug_melvin)
Date: 2005-07-29 12:17

Message:
Logged In: YES 
user_id=184788

Confirmed: _delete() is depecriated code.
The correct call is _destroy()

Please implement in cvs copy and and close this bug.

Thanks (I'll check if i have cvs write access this evening)

The change:
Line 159 of event.js:
change from: c._delete();
to: c._destroy();

----------------------------------------------------------------------

Comment By: Raymond Irving (xwisdom)
Date: 2003-08-14 17:15

Message:
Logged In: YES 
user_id=696242

I believe the lastest snapshot should have fixed this problem. 
I did add _destroy() to the deleteChild() function and made 
some other changes that fixed the problem. 

Keep up the good work.


----------------------------------------------------------------------

Comment By: Andrew Gillett (agillett)
Date: 2003-08-14 16:48

Message:
Logged In: YES 
user_id=134108

Hmm, we could have: remove, delete, destroy and dispose.

> I see what's happening. IMO deleteChild() and removeChild
> means the same thing, correct?
No. To my way of thinking, 'delete' should be like the C++ 
keyword - once deleted an object no longer exists.  And why 
have both deleteChild and removeChild if they do the same 
thing?

IMO we should just add the _destroy() function to deleteChild 
and update the documentation accordingly.


----------------------------------------------------------------------

Comment By: Raymond Irving (xwisdom)
Date: 2003-08-14 06:02

Message:
Logged In: YES 
user_id=696242


Thanks for the feedback

Ok. Will keep the delete functions them _destroy() the layers 
as well.


----------------------------------------------------------------------

Comment By: L W (warp9pnt9)
Date: 2003-08-14 05:30

Message:
Logged In: YES 
user_id=706287

My view on the matter.

I think the naming convention would be clearer if the
function that removes children from parents was called
removeChild / removeFromParent, but not destroying the
layer.  I think this is how it works now.  I think the
function that removes the child from the parent AND destroys
the layer should be called deleteChild / deleteFromParent or
maybe destroyChild / destroyFromParent.  I think it's
confusing to add a new name "dispose" when it doesn't
intuitively correspond to an underlying "dispose" function.
 It's a little vague.

----------------------------------------------------------------------

Comment By: Raymond Irving (xwisdom)
Date: 2003-08-13 19:37

Message:
Logged In: YES 
user_id=696242


I see what's happening. IMO deleteChild() and removeChild 
means the same thing, correct? 

When a child layer is removed from the parent it's actually 
deleted from the parent, correct?  The layer is not completly 
destroyed as a reference to it still exists within DynObject.all 
collection. 

Calling _destroy() during a deleteChild() function will not only 
delete the child from its parent but it will also dispose of the 
child object.

I think we should change deleteChild/AllChildren/etc to 
disposeChild/AllChildren/etc wihich will clearly define what is 
been done to the object. The dispose functions will complete 
remove and destroy the object.

Are we all in agreement with changing delete to dispose? Or 
should we add the _destroy() function to deleteChild and 
keep the delete functions?  

(Note: If we keep the delete functions we'll have to 
document that it will completely destroy and remove the layer 
from the system.)



----------------------------------------------------------------------

Comment By: Andrew Gillett (agillett)
Date: 2003-08-13 17:31

Message:
Logged In: YES 
user_id=134108

> Are you using the lastest snapshot?
Yes, I check out the code directly from CVS.
> What browsers are experiencing this memory leak?
IE6 & Mozilla1.4, but that is not really relevant.

On 29/07/2003 12:26 AM (my time), in response to my post 
about a bug in deleteAllChildren(), you wrote:
>To fix the memory and layer problem use the following:
>
>p.deleteAllChildren = function() {
>	var c,l = this.children.length;
>	for(var i=0;i<l;i++) {
>		c=this.children[i];
>		if(c) {
>			c._destroy();
>			c._created = c.isChild = false;
>		};
>		delete this.children[i];
>	}
>	this.children.length = 0;
>};
>
This fix worked perfectly. The _destroy() method is called on 
each child of the layer.

However this is not what was put into CVS.  In the current 
version of event.js, deleteAllChildren() calls deleteFromParent
() which calls deleteChild() which calls _delete() instead of 
_destroy().

It is the call to _delete() that I have a problem with.  There 
is simply no such function.  In line 184 of event.js there is:

... = p._delete = p._destroy = dynapi.functions.Null;

but nowhere else in the entire source tree is _delete() 
defined.


Try the attached example.  On my Windows XP system, IE 
grows by about 6MB each time the "Memory Leak" button is 
pressed.  But if I replace the call to _delete() with a call to 
_destroy() in the deleteChild function, then IE doesn't leak at 
all.


----------------------------------------------------------------------

Comment By: Raymond Irving (xwisdom)
Date: 2003-08-13 06:53

Message:
Logged In: YES 
user_id=696242

Are you using the lastest snapshot?

What browsers are experiencing this memory leak?

You can get the lastest snapshot here:
http://dynapi.sourceforge.net/snapshot/?N=D


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105757&aid=787137&group_id=5757