Ely, yeah, that's what I had done so far. But of course you see the problem and the inconvenience in that you have to do it for every chart subclass. I'll log an enhancement request now. Just wanted to check to make sure I wasn't missing anything first.
I flipped over to my browser and thought "no way Ely has posted an answer already." But then you proved me wrong. ;) On 5/14/07, Ely Greenfield <[EMAIL PROTECTED]> wrote:
Hi Jason. Probably not a great reason why it shouldn't be exposed, other than it wasn't designed to be. i.e., log a bug, enhancement request, etc. because I think it's a good idea. In the meantime, if you want, you could subclass your chart type, and define a method: Public function publicInvalidateDataBecauseElyIsStupid():void { This.invalidateData(); } But since invalidateData wasn't designed to be a publicly visible method, no guarantees on what bad effects this will have. None that I can think of, just keep your cat away from the computer the first time you run it J Ely. *From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On Behalf Of *Pan Troglodytes *Sent:* Monday, May 14, 2007 9:18 AM *To:* flexcoders *Subject:* [flexcoders] ChartBase.invalidateData() Is there some reason I'm missing that ChartBase.invalidateData() shouldn't be moved from protected to public? Or is there some other (equivalently good) way to do the same thing? I'm working on code to add one data point at a time to the chart. I'm doing this by adding them to the array of the underlying data provider. I know there's ways around it, like reassigning the dataprovider or using an ArrayCollection. I'm just wondering what good it does not to expose it. Seems like a very important function to be marked as protected. -- Jason
-- Jason
