--- In [email protected], "Tim Hoff" <[EMAIL PROTECTED]> wrote: > > > Hi Amy, > > I guess that everyone has their own perspective. Like you, I used to > complain that the flex styles weren't as comprehensive as the .net > controls that I was used to at the time. However, looking at it from an > 80-20 point of view, the basics are there; especially for charts. The > point is that I'll gladly sacrifice some built-in properties, if the > framework supports rolling my own components and/or extending; to > customize properties. Sometimes, it takes more time and effort to > complain about something, than it does to just create it yourself. > Here's a solution that took very little time to create:
Thanks, and I do appreciate it--I don't mean to sound ungrateful. But the point of my question was not to complain. Literally every time I have gone to "roll my own" solution to something that at first seemed to be missing from Charts, I discovered that it was already covered by the charting FW. And this is nice--really nice-- since I have never had a week where I literally did not have to recode _anything_, it just worked as advertised. While exploring charting, the majority of examples I have found have used a hack to solve a problem that doesn't exist in charting: http://www.rphelan.com/2008/05/23/taking-control-of-flex-charting- styles/ uses a tick mark the same color as the background instead of labelgap http://blogs.adobe.com/flexdoc/2008/07/customized_legend_layout.html rewrites the Legend control rather than just set a width on the Legend and on and on... The problem, as I see it, is that when people run up against a percieved limitation like this, they immediately run out and write something to "fix" it. This robs the Adobe team of the motivation to provide nice, user-friendly components like charting if they know people aren't going to use the in-built functionality if they can't find the feature in the 3 seconds they spend with the docs. After all, if it takes 20 hours to write a feature, 20 hours to qa it, and 20 hours to document it, if nobody ever uses it because they are so used to running out an building their own at the first hint of trouble, why would Adobe invest the time? I've been as guilty of it as anyone, but I intent to do my absolute darnedest to make sure I'm leveraging what's in the features before I go off and write something custom. I come from a history of developing in a product Adobe doesn't make anymore--Authorware. Most Authorware developers say there's a double learning curve with that product. First, you learn the icons and flow line (analagous to MXML) and then you learn the code. Most developers stop there, but a very few take the third curve--going back and _really_ learning the icons and _not_ coding features that were already beautifully, elegantly implemented in the icons. Because I've been through all three curves with another product that is similar in some ways to Flex, I know that I can save myself a lot of effort if I try to integrate the third curve with the first and second curves. I sincerely believe there _is_ a simple solution to this problem that already exists in the charting framework. And that is the answer I'm asking for. It's a question, not a complaint. Thanks :-) -Amy
