| Author |
 Topic  |
|
|
chadb
6 Posts |
 Posted - 22 Nov 2003 : 01:58:07
|
It would be really helpful if the ChartObj.* enums were catagorized in some way (and these catagories were in the help file method descriptions). I feel like I spend about 50% of my dev time w/ this component just trying to figure out the valid "flags" to pass...
Thanks,
Chad
p.s. *really* nice component!
|
|
|
quinncurtis
1164 Posts |
Posted - 22 Nov 2003 : 09:50:54
|
You have a valid point. We originally had the constants spread out over all of the classes, each in the class associated with it. This would be the categorization you describe. But we found a huge number of duplications among constants in many classes. So we tried to minimize the duplications by grouping them together in the base ChartObj class. Ultimately we found grouping them together in ChartObj to be the less elegant, easier to use format.
If you know the constants name, you always know where it is, in the ChartObj class. Finding the constants name is the purpose of the documentation. We try and list the constants associated with a given property or method in the documentation, but probably do not do as good as a job as we should.
|
 |
|
|
ryan
1 Posts |
Posted - 04 Dec 2006 : 17:07:52
|
I agree with the original suggestion. The standard way to do this in C# is to use enumerations. With enumerations you get type-safe calls and intellisense support (which is the main thing I'm wishing for). Since you can have [Flags] enumerations, the underlying data type for an enum can be specified (default is int), and you can cast back and forth, your underlying values don't have to change, so it's easy for you to implement. You can overload your methods to so that user code could call with either the integer or enum values, for an easy transition. You can mark the ones that take the ints with Deprecated attribute so that people are reminded that new code should use the new enums.
|
|
|
| |
Topic |
|
|
|
ChartObj Suggestion
