>> Well, it is triggered whenever the corresponding class code might have >> changed, so a simple 'touch' on the class file will do that for you, you >> don't need to actually change the code :). > > I have to say: No! A simple 'touch' doesn't change anything -- The generator > even continues to complain about this issue when I add several lines of > code!!!
After a cache clean, does the misbehavior show up "all of a sudden" after some while, or only if you actually changed the affected class (like infodesk.ui.info.WinAbout)? > See my notes above. The generator keeps using the corrupted cache _even_ when > I > change a whole bunch of files! > Only the *new* keyword seems to change this (Note the 'seems' in that sentence > ;) I am not 100% sure if this is really the trigger for re-creating the cache) Well, I would be very surprised if the cache handling would be that strange. As I said, the problem seems to be cosmetical, so a whole bunch of other things seem to work fine. Of course, 'new' is potentially injecting a new dependency, but really isn't in your case, as you wrote earlier you are instantiating classes you have already used in the module. So you are actually not adding a new dependency. Could you run a 'generate.py info' and post the output? Are you at liberty to disclose the code of the infodesk.ui.info.WinAbout class, potentially with markers where you inserted the new 'new' expression? T. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
