Re: destruct() question

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: destruct() question

Romain FLIEDEL
thron7 a écrit :
Ah, you guys got us with our pants down :). Yes, these are actually 
leaks in the framework. I've fixed those from the log output in 
legacy_0_7_x (but maybe there are more). If you check your applications 
and come across further 'Missing' entries that pertain to framework 
classes, do file them (either through mailing list or bugzilla), this is 
always helpful for us. Of course, patches are welcome.

I have also expanded the destructor wiki page a little.

Cheers,
Thomas

  
Hi Thomas,

Here are some other missing destruct that I found :

qx.ui.treevirtual.SimpleTreeDataModel
Missing destruct definition for '_nodeArr'
Missing destruct definition for '_nodeRowMap'
Missing destruct definition for '_selections'
Missing destruct definition for '__tree'

qx.ui.treevirtual.SelectionManager
Missing destruct definition for '_table'

qx.ui.table.model.Filtered
Missing destruct definition for 'numericAllowed'
Missing destruct definition for 'betweenAllowed'

qx.ui.table.pane.CellEvent
Missing destruct definition for '_scroller'

qx.ui.table.pane.Pane
Missing destruct definition for '_tableContainer'

qx.ui.form.ComboBox
Missing destruct definition for '_oldSelected'

Cheers,
Romain


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: destruct() question

Peter Schneider
Hi Thomas,

I've noticed another small issue:

When a table object is created and disposed again, the event-listener to
"changeLocale" is still attached, which will lead to an error when the locale
is changed after table object disposal.

The attached patch worked for our application, but is not tested any further.
Feel free to take a look at it (it's not _that_ complicated ;) ) and commit to
the qooxdoo_legacy_0_7_x branch.

Greetings,

  Kuddel


> [...]
> Ah, you guys got us with our pants down :). Yes, these are actually
> leaks in the framework. I've fixed those from the log output in
> legacy_0_7_x (but maybe there are more). If you check your applications
> and come across further 'Missing' entries that pertain to framework
> classes, do file them (either through mailing list or bugzilla), this is
> always helpful for us. Of course, patches are welcome.
>
> I have also expanded the destructor wiki page a little.
>
> Cheers,
> Thomas
>
> [...]

Index: Table.js
===================================================================
--- Table.js (revision 13985)
+++ Table.js (working copy)
@@ -1941,6 +1941,11 @@
 
   destruct : function()
   {
+    // remove the event listener which handled the locale change
+    qx.locale.Manager.getInstance().removeEventListener("changeLocale",
+                                                        this._onChangeLocale,
+                                                        this);
+
     // we allocated these objects on init so we have to clean them up.
     var selectionModel = this.getSelectionModel();
     if (selectionModel)

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: destruct() question

thron7
Thanks, guys, for the postings.

Thomas

> Hi Thomas,
>
> I've noticed another small issue:
>
> When a table object is created and disposed again, the event-listener to
> "changeLocale" is still attached, which will lead to an error when the locale
> is changed after table object disposal.
>
> The attached patch worked for our application, but is not tested any further.
> Feel free to take a look at it (it's not _that_ complicated ;) ) and commit to
> the qooxdoo_legacy_0_7_x branch.
>
> Greetings,
>
>   Kuddel
>
>
>  
>> [...]
>> Ah, you guys got us with our pants down :). Yes, these are actually
>> leaks in the framework. I've fixed those from the log output in
>> legacy_0_7_x (but maybe there are more). If you check your applications
>> and come across further 'Missing' entries that pertain to framework
>> classes, do file them (either through mailing list or bugzilla), this is
>> always helpful for us. Of course, patches are welcome.
>>
>> I have also expanded the destructor wiki page a little.
>>
>> Cheers,
>> Thomas
>>
>> [...]
>>    
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> qooxdoo-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: destruct() question

Romain FLIEDEL
I've seen that you add missing destructs in rev 14009
I found an issue with qx.ui.table.pane.CellEvent

I think you should use disposeFields instead of disposeObjects because
right now if a CellEvent is triggered then the table seems not to react
on click anymore (no focus change for instance)
With the patch bellow it seems to be working (and the disposer doesn't
complain)

Index: CellEvent.js
===================================================================
--- CellEvent.js    (revision 14042)
+++ CellEvent.js    (working copy)
@@ -116,6 +116,6 @@
 
   destruct : function()
   {
-    this._disposeObjects("_scroller");
+    this._disposeFields("_scroller");
   }
 });

You should probably check that such problem have not been introduced in
the other corrections you made
(I'm sorry I don't have enough time to help you correcting those bugs)


thron7 a écrit :
> Thanks, guys, for the postings.
>
> Thomas
>  



This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.



-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: destruct() question

Romain FLIEDEL
In reply to this post by thron7
I've seen that you add missing destructs in rev 14009
I found an issue with qx.ui.table.pane.CellEvent

I think you should use disposeFields instead of disposeObjects because
right now if a CellEvent is triggered then the table seems not to react
on click anymore (no focus change for instance)
With the patch bellow it seems to be working (and the disposer doesn't
complain)

Index: CellEvent.js
===================================================================
--- CellEvent.js    (revision 14042)
+++ CellEvent.js    (working copy)
@@ -116,6 +116,6 @@

   destruct : function()
   {
-    this._disposeObjects("_scroller");
+    this._disposeFields("_scroller");
   }
});

You should probably check that such problem have not been introduced in
the other corrections you made
(I'm sorry I don't have enough time to help you correcting those bugs)


thron7 a écrit :
> Thanks, guys, for the postings.
>
> Thomas
>  




This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.



-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: destruct() question

Hugh Gibson-2
In reply to this post by Romain FLIEDEL
> I think I have to jump in this discussion.
> I've a problem with memory usage of my qooxdoo application too and
> tried the mentioned hints.
> If I use the additional options in the make file to show the
> missing destruct definitions, the only messages I see, come from
> the framework itself:
>
> 035443 DEBUG: testgui.Report[1004]: Disposing: [object
> testgui.Report]FireBug.js (line 75)
> Missing destruct definition for '_scroller' in
> qx.ui.table.pane.FocusIndicator[1111]: [object
> qx.ui.table.pane.Scroller]Log.js (line 557)

> qx.ui.table.pane.FocusIndicator[1654]: [object
> qx.ui.table.pane.Scroller]Log.js (line 557)
> Missing destruct definition for '_lastMouseDownCell' in
> qx.ui.table.pane.Scroller[1629]: [object Object]Log.js (line 557)

> Missing destruct definition for '_scroller' in
> qx.ui.table.pane.FocusIndicator[4545]: [object
> qx.ui.table.pane.Scroller]Log.js (line 557)
>
> Could anyone give me a hint if these missing destruct definitions
> are my fault? Or if a qooxdoo developer has to look at their
> destructors ;)

Don't forget that there's a number of problems with tables in that
objects are created to implement functionality in the table, and passed
through in the constructor or "set" calls. However, it's not clear which
class is then responsible for disposing of them. There's an extended
discussion about memory leaks caused by this at
http://bugzilla.qooxdoo.org/show_bug.cgi?id=753

There may be framework errors from this (see message about combobox).
Fixing these can't be done by simple dispose calls - there's a more
complex question about who has ownership of the created subsidiary
objects.

Also, I've just taken a quick look at some of the code you checked in
from the patches here and I'm not sure that it's correct due to an
ownership issue. I haven't reviewed it completely, but found the
following.

qx.ui.table.pane.CellEvent is passed an instance of the parent
qx.ui.table.pane.Scroller object in the constructor, e.g. in
_onMouseupFocusIndicator:

this.dispatchEvent(new qx.ui.table.pane.CellEvent(this,
"cellClick", e), true);

CellEvent stores the scroller instance in the _scroller member.
         
With revision 14009 you added this code to CellEvent:

  destruct : function()
  {
    this._disposeObjects("_scroller");
  }

But when the cell event has finished, you definitely don't want to be
destroying the parent scroller object!

This needs a lot more careful analysis.

And finally could I say that tracing the patches and reasons for changes
is very difficult when you haven't got an issue for them, with full
logging of issue number in SVN checkin messages; and SVN revision numbers
in the issue.
 
Hugh

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: destruct() question

Hugh Gibson-2
> Also, I've just taken a quick look at some of the code you checked
> in
> from the patches here and I'm not sure that it's correct due to an
> ownership issue. I haven't reviewed it completely, but found the
> following.

I see that Romain has already reported the problem that resulted from
this checkin.

Hugh

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: destruct() question

thron7
In reply to this post by Romain FLIEDEL
Romain FLIEDEL wrote:

> I've seen that you add missing destructs in rev 14009
> I found an issue with qx.ui.table.pane.CellEvent
>
> I think you should use disposeFields instead of disposeObjects because
> right now if a CellEvent is triggered then the table seems not to react
> on click anymore (no focus change for instance)
> With the patch bellow it seems to be working (and the disposer doesn't
> complain)
>
> Index: CellEvent.js
> ===================================================================
> --- CellEvent.js    (revision 14042)
> +++ CellEvent.js    (working copy)
> @@ -116,6 +116,6 @@
>  
>    destruct : function()
>    {
> -    this._disposeObjects("_scroller");
> +    this._disposeFields("_scroller");
>    }
>  });
>
> You should probably check that such problem have not been introduced in
> the other corrections you made
> (I'm sorry I don't have enough time to help you correcting those bugs)
>
>  

Well, reporting the issues is in itself a big help, so don't worry too
much. I've changed the code. The problem is really that the disposer can
only hint at issues, but you cannot just mechanically poor all the
'missing' messages into the 'destruct' section (otherwise we would
probably do it automatically in the framework :). Data items can be
shared between object instances and only if you know the whole widget
code can you decide whether a data item should be released with the
destruction of this particlular instance, or if it is still used by some
other instance - the disposer complaining or not. - I'm not sure about
all possible side effects myself so this process is a bit of a trial and
error, and depends on you guys to give feedback if things go astray :).

In this particular case it's really a hack to use _disposeFields to
silence the disposer, since according to the doc _scroller is a proper
qooxdoo object instance which you should use _disposeObject for. But
there you go...

Thomas


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: destruct() question

thron7
In reply to this post by Hugh Gibson-2
Hugh Gibson wrote:
>
> There may be framework errors from this (see message about combobox).
> Fixing these can't be done by simple dispose calls - there's a more
> complex question about who has ownership of the created subsidiary
> objects.
>  

Well said.

>
> But when the cell event has finished, you definitely don't want to be
> destroying the parent scroller object!
>  

I've corrected this, thanks to a report from Romain.


> This needs a lot more careful analysis.
>  

That's perfectly true. Actually, I thought the primary widget
maintainers would jump in and take over for their respective code. As
this didn't happen, I thought the next best thing would be to give it a
go, and then sort out any issues with missing objects that come up. All
I want to achieve is a consolidated situation where all remaining
'missing' messages of the disposer have to be in and be in for a reason
("Faking" object disposal with _disposeFields as now in CellEvent might
be a good way of showing it has been taken care of).

> And finally could I say that tracing the patches and reasons for changes
> is very difficult when you haven't got an issue for them, with full
> logging of issue number in SVN checkin messages; and SVN revision numbers
> in the issue.
>  

I see what you're hinting at. I'm not sure, though, this "double
bookkeeping" is feasible for us, but that's only my 2 cents.

Thomas


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: destruct() question

Hugh Gibson-2
> > And finally could I say that tracing the patches and reasons for
> > changes is very difficult when you haven't got an issue for them,
> > with full logging of issue number in SVN checkin messages; and SVN
> > revision numbersin the issue.
>
> I see what you're hinting at. I'm not sure, though, this "double
> bookkeeping" is feasible for us, but that's only my 2 cents.

I've been doing it for years. We even have Tortoise SVN configured to
require a bug number (or list of bug numbers) for a checkin. So our
developers can't commit code unless there is a bug allocated.

In the case of this work you remember where the discussion was about the
changes because they are fresh in your mind. But in one year's time you
will forget and trying to track down why something was done is very
difficult. Someone who has skimmed this thread will have difficulty
tracking it down from day 1.

This is particularly the case where there is a bit of code which doesn't
appear to have any reason for being there. If your comments in the code
aren't clear then the next resource to use is to look for the bug and
discussion about it. SVN Blame is very useful for finding the checkin
which modified a line, but then finding the reasons why can be difficult
if there's no cross-referencing.

If you have full regression and code coverage testing you can be less
concerned as you can just delete the dodgy code and see what happens -
but I don't think you've got that.

It might take some more time when checking in - but it certainly saves
time when maintaining code later.

Hugh

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: destruct() question

Derrell Lipman
In reply to this post by thron7
On Mon, Jun 23, 2008 at 3:36 AM, thron7 <[hidden email]> wrote:
> This needs a lot more careful analysis.

That's perfectly true. Actually, I thought the primary widget
maintainers would jump in and take over for their respective code.

Unfortunately, the author of Table hasn't been seen here for years.  Until recently, I think I've been the next most familiar with the code and I believe I'm indicated as the widget maintainer, but even I don't have the intimate knowledge of the inter-relationships between the helper classes required to solve this problem (nor, unfortunately, the time right now to study it adequately to gain that knowledge).  Table is a fabulous widget, is incredibly powerful, and has some great features.  As an initial implementation, it was quite an accomplishment.  There are, however, some seriously incestuous relationships going on there that are difficult to untangle.  One of these years, the widget should be rewritten with the benefit of 20-20 hindsight and the issues it's had, and with the a cleaner design and separation between the various classes.

Derrell


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: destruct() question

Peter Schneider
In reply to this post by thron7
Hi Thomas,

according to your request in the log of R14009 (legacy 0.7.x),
 "...please check for unintended side effects."
I can offer a patch to another (new) destructor issue:

The _tableContainer object in qx.ui.table.pane.Pane is created with
 document.createElement("div");
and is therefore no qooxdoo-object to be destroyed by _disposeObjects().
I'm not sure if the object should be disposed at all (by _disposeFields()) ...
does anyone have information on that?

If it should be destroyed, see (the very obvious ;) ) patch for details

/Kuddel


> [...]
> Well, reporting the issues is in itself a big help, so don't worry too
> much. I've changed the code. The problem is really that the disposer can
> only hint at issues, but you cannot just mechanically poor all the
> 'missing' messages into the 'destruct' section (otherwise we would
> probably do it automatically in the framework :). Data items can be
> shared between object instances and only if you know the whole widget
> code can you decide whether a data item should be released with the
> destruction of this particlular instance, or if it is still used by some
> other instance - the disposer complaining or not. - I'm not sure about
> all possible side effects myself so this process is a bit of a trial and
> error, and depends on you guys to give feedback if things go astray :).
>
> In this particular case it's really a hack to use _disposeFields to
> silence the disposer, since according to the doc _scroller is a proper
> qooxdoo object instance which you should use _disposeObject for. But
> there you go...
>
> Thomas

Index: qooxdoo/frontend/framework/source/class/qx/ui/table/pane/Pane.js
===================================================================
--- qooxdoo/frontend/framework/source/class/qx/ui/table/pane/Pane.js (revision 14067)
+++ qooxdoo/frontend/framework/source/class/qx/ui/table/pane/Pane.js (working copy)
@@ -746,9 +746,7 @@
       window.clearTimeout(this._layoutPending);
     }
 
-    this._disposeObjects(
-      "_paneScroller",
-      "_tableContainer"
-    );
+    this._disposeObjects("_paneScroller");
+    this._disposeFields("_tableContainer");
   }
 });

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: destruct() question

thron7
Thanks, Kuddel, for the submission. I'm actually getting to the point,
if it looks like I've de-stabilized the code with all the 'destruct'
entries too much, I'm going to revert all my changes and file bug
reports for each, so people can sort them out with more time and
subtlety. We'll see...

Thomas


> Hi Thomas,
>
> according to your request in the log of R14009 (legacy 0.7.x),
>  "...please check for unintended side effects."
> I can offer a patch to another (new) destructor issue:
>
> The _tableContainer object in qx.ui.table.pane.Pane is created with
>  document.createElement("div");
> and is therefore no qooxdoo-object to be destroyed by _disposeObjects().
> I'm not sure if the object should be disposed at all (by _disposeFields()) ...
> does anyone have information on that?
>
> If it should be destroyed, see (the very obvious ;) ) patch for details
>
> /Kuddel
>
>
>  
>> [...]
>> Well, reporting the issues is in itself a big help, so don't worry too
>> much. I've changed the code. The problem is really that the disposer can
>> only hint at issues, but you cannot just mechanically poor all the
>> 'missing' messages into the 'destruct' section (otherwise we would
>> probably do it automatically in the framework :). Data items can be
>> shared between object instances and only if you know the whole widget
>> code can you decide whether a data item should be released with the
>> destruction of this particlular instance, or if it is still used by some
>> other instance - the disposer complaining or not. - I'm not sure about
>> all possible side effects myself so this process is a bit of a trial and
>> error, and depends on you guys to give feedback if things go astray :).
>>
>> In this particular case it's really a hack to use _disposeFields to
>> silence the disposer, since according to the doc _scroller is a proper
>> qooxdoo object instance which you should use _disposeObject for. But
>> there you go...
>>
>> Thomas
>>    
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> qooxdoo-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: destruct() question

Peter Schneider
Hi again Thomas,

> [...]
> if it looks like I've de-stabilized the code with all the 'destruct'
> entries too much, I'm going to revert all my changes and file bug
> reports for each, so people can sort them out with more time and
> subtlety. We'll see...
> [...]

I don't think that you've de-stabilized it too much!
Let's face it: There are not that many people around willing do that job :-/
...me neither
So keep up the good work!

Best

  Kuddel



>
> Thomas
>
>
>> Hi Thomas,
>>
>> according to your request in the log of R14009 (legacy 0.7.x),
>>  "...please check for unintended side effects."
>> I can offer a patch to another (new) destructor issue:
>>
>> The _tableContainer object in qx.ui.table.pane.Pane is created with
>>  document.createElement("div");
>> and is therefore no qooxdoo-object to be destroyed by _disposeObjects().
>> I'm not sure if the object should be disposed at all (by _disposeFields()) ...
>> does anyone have information on that?
>>
>> If it should be destroyed, see (the very obvious ;) ) patch for details
>>
>> /Kuddel
>>
>>
>>  
>>> [...]
>>> Well, reporting the issues is in itself a big help, so don't worry too
>>> much. I've changed the code. The problem is really that the disposer can
>>> only hint at issues, but you cannot just mechanically poor all the
>>> 'missing' messages into the 'destruct' section (otherwise we would
>>> probably do it automatically in the framework :). Data items can be
>>> shared between object instances and only if you know the whole widget
>>> code can you decide whether a data item should be released with the
>>> destruction of this particlular instance, or if it is still used by some
>>> other instance - the disposer complaining or not. - I'm not sure about
>>> all possible side effects myself so this process is a bit of a trial and
>>> error, and depends on you guys to give feedback if things go astray :).
>>>
>>> In this particular case it's really a hack to use _disposeFields to
>>> silence the disposer, since according to the doc _scroller is a proper
>>> qooxdoo object instance which you should use _disposeObject for. But
>>> there you go...
>>>
>>> Thomas
>>>    


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel