I don't know think that too many people are actually using the exising
<debug> tag attributes, except for width and height and x, y on the view...


On Wed, Sep 1, 2010 at 9:45 AM, P T Withington <[email protected]> wrote:

> 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?
>
>
>


-- 
Henry Minsky
Software Architect
[email protected]

Reply via email to