--- In flexcoders@yahoogroups.com, Josh McDonald [EMAIL PROTECTED] wrote:
Not sure I follow what you want, but could you manipulate a view of
your
data, rather than having to mess about with charting internals? I
don't know
much about charting so I don't know how much you can customize
Hi Amy, both the column series and the line series use the same
horizontal axis
mx:horizontalAxis
mx:CategoryAxis id=hAxis categoryField=mfg/
/mx:horizontalAxis
mx:series
mx:ColumnSeries id=colPrevSeries
horizontalAxis={hAxis} ...
mx:ColumnSeries id=colCurrSeries
--- In flexcoders@yahoogroups.com, chigwell23 [EMAIL PROTECTED]
wrote:
Hi Amy, both the column series and the line series use the same
horizontal axis
mx:horizontalAxis
mx:CategoryAxis id=hAxis categoryField=mfg/
/mx:horizontalAxis
mx:series
mx:ColumnSeries id=colPrevSeries
--- In flexcoders@yahoogroups.com, chigwell23 [EMAIL PROTECTED]
wrote:
Again thanks for all the help so far ... turns out that
LineSeries.RenderData is a protected property
renderDataproperty
renderData:Object [read-only]
Stores the information necessary to render this
If it's a protected read-only, you won't be able to expose it without
monkey-patching the original file, as _renderData is almost certainly going
to be private, so you can never set it.
-Josh
On Fri, Aug 1, 2008 at 8:37 AM, Amy [EMAIL PROTECTED] wrote:
--- In flexcoders@yahoogroups.com,
Yes Josh it is protected read-only why would the flex developers
intentionally cripple the functionality like this? Rhetorical question
I guess :-(
--- In flexcoders@yahoogroups.com, Josh McDonald [EMAIL PROTECTED] wrote:
If it's a protected read-only, you won't be able to expose it
If it's actually read-only, and doesn't have an mx_internal way to mess with
it, then it probably means that it's not really a variable, because it's
immutable. Think of it as a late-set constant. If they've written a bunch of
logic that depends on the immutability of a property and you mess with
If you need to override functions in framework components that are
private (or what have you), why not just copy all of the code from
that component and make your own? Sure, future functionality might be
in-the-air, but for Flex3 stuff certain off-limits stuff is sometimes
needed.
--- In
Indeed, hence my monkey-patch recommendation. I've got several
monkey-patches in the SOAP encoder code that we include in all our projects.
When and if my fixes all make it into svn then we'll monkey-patch with the
official file, and when they make it into a release we'll use that. But
don't be
: [flexcoders] Re: Overriding function not marked for
override?
Indeed, hence my monkey-patch recommendation. I've got several
monkey-patches in the SOAP encoder code that we include in all our
projects. When and if my fixes all make it into svn then we'll
monkey-patch with the official file, and when
.
From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Josh McDonald
Sent: Thursday, July 31, 2008 8:19 PM
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] Re: Overriding function not marked for
override?
Indeed, hence my monkey
11 matches
Mail list logo
