The bug with layout does not happen when debug=true, can you think of any thing off the top of your head in that change that might be dependent on the debug flag?
I'm going to try to get a minimal test case for the radiobutton drawing bug, and then compare the debug and non-debug js output code, maybe something obvious will be different... On Thu, Dec 3, 2009 at 8:19 AM, P T Withington <[email protected]> wrote: > You should link the two bugs to LPP-8088, but also note the _long_ history > of 8088. > > We _really_ want to keep the set of changes in 8088, because it greatly > improves the efficiency of the event system (hugely reduces the number of > function calls on startup of your favorite large application). > > Here's the $0.05 summary, which may give you some clues: > > 8088 made it so that events are _not_ sent when you set an attribute to the > same value, on the theory if the value does not change, then none of the > dependent expressions can change. > > In order to detect when a value is changed, all constrained values start > out as `void 0` (undefined), but we know that will propagate as `NaN` in > numeric operations, so, before any constraints are applied, all values that > will be constrained are set to `null`. Finally, while an object is being > initialized, events are _always_ sent, because our constraint system > (apparently) relies on a superfluity of events to get circular dependencies > to settle. [There is surely a better way to solve this problem, like > implement a real constraint-solver, but we've gotten by so far...] > > Bottom line is, you probably need to trace the application of constraints > to see where things are going awry... Probably the layout is looking at the > views before their dimensions have settled. > > On 2009-12-03, at 07:33, Henry Minsky wrote: > > > Regarding LPP-8639 and LPP-8626, I did a binary search and this change > seems > > like it is partially responsible. > > This change makes the radio buttons render correctly again in the dev > > console (you need to explicitly recompile > > the dev console to see the change, of course) but doesn't seem to make > any > > difference to the layout of the > > first list component example. > > > > But I'll see if I can see what's happening to the radio button, and maybe > > that will give a clue as to what > > might be wrong with the list component. > > > > > > > > r13837 | ptw | 2009-05-08 15:44:23 -0400 (Fri, 08 May 2009) | 25 lines > > > > Change 20090508-ptw-G by [email protected] on 2009-05-08 10:52:53 > EDT > > in /Users/ptw/OpenLaszlo/trunk-2 > > for http://svn.openlaszlo.org/openlaszlo/trunk > > > > Summary: Ensure dynamic properties are created in instances > > > > Bugs Fixed: LPP-8088 DHTML: many warnings from applyConstraintMethod() > > (partial) > > > > Technical Reviewer: max (Message-ID: <[email protected] > >) > > QA Reviewer: hminsky (pending) > > > > Details: > > Clean up the code in LzNode that makes sure dynamic properties > > exist by using a cross-platform test: if accessing the dynamic > > property returns undefined, make sure it exists in the instance by > > setting it to undefined. > > > > This does not fix the warning part of the bug, but it does make > > swf9 work again. > > > > Tests: > > http://localhost:8080/4.2/test/extensions/html.lzx?lzr=swf9 No > > longer gets a runtime error. > > > > > > > > > > -- > > Henry Minsky > > Software Architect > > [email protected] > > -- Henry Minsky Software Architect [email protected]
