So, should the preferences object become the way you control the debugger and the individual preferences be deprecated? I'm leery of having multiple interfaces. But, the only way I can think of to document the combined preferences then is to make a separate debugprefs class... Ugh.
On the 3rd hand, I guess I need something like that so I can get their types right and correctly accept values out of the preferences object into them. Kind of a bigger can of worms than I wanted just now... On 2010-08-31, at 13:25, Max Carlson wrote: > Sounds good! > > Regards, > Max Carlson > OpenLaszlo.org > > On 8/31/10 9:26 AM, P T Withington wrote: >> I'm working on >> >> LPP-9311 flash halts in backtrace mode but not in debug mode when dealing >> with deeply nested views >> >> and one piece of the puzzle (I think) is to ensure that the debugger's >> notion of maximum stack depth is within the underlying runtime's limit. In >> the case of SWF, we have a canvas property `scriptlimits` that lets you >> specify the maximum recursion and timeout values for the player. (See >> LPP-6132 debug.backtraceStack.maxDepth attribute should be copied form >> scriptlimits recursion depth). >> >> To do this, I plan to pass a debugger `preferences` object through the >> console window (as embodied by the<debug> tag). Since I'm in there, I >> figure I might as well surface this in the tag, so you will be able to say >> things like: >> >> <debug ... preferences="print-length: 256, print-depth:32, >> show-internal-properties: true" /> >> >> My thought is to compile the preferences as a CSS properties list and use >> the normal CSS mapping of hyphens to camel case, e.g.: >> >> camel-case -> camelCase >> >> to translate CSS properties to debugger attributes. >> >> Comments?
