Fixing CorePlot’s CPPlotRange Core Animation Type Encoding
A few days ago, I started working on Issue #2 for CorePlot. I worked on this for quite a while trying to get the NSDecimal ivars on the CPCartesianPlotSpace to encode properly in Core Animation, but to no avail. The things I read on Google are basically that if it's not an object that conforms to the NSCoder protocol, then the data type has to be understood by Core Animation. That means it has to be a CG-prefaced data type. Fair enough.
The problem manifests itself as a run-time error message like:
2009-02-11 13:49:39.126 CPTestApp[26427:10b] unhandled property type encoding:
`{_CPPlotRange="location"{?
="_exponent"b8"_length"b4"_isNegative"b1"_isCompact"b1"_reserved"b18"_mantissa"[8S]}
"length"{?="_exponent"b8"_length"b4"_isNegative"b1"_isCompact"b1"_reserved"b18"
_mantissa"[8S]}}'
2009-02-11 13:49:39.128 CPTestApp[26427:10b] unhandled property type encoding:
`{_CPPlotRange="location"{?
="_exponent"b8"_length"b4"_isNegative"b1"_isCompact"b1"_reserved"b18"_mantissa"[8S]}
"length
"{?="_exponent"b8"_length"b4"_isNegative"b1"_isCompact"b1"_reserved"b18"
_mantissa"[8S]}}'
I talked to Drew about this and told him that the only way I could see to fix it was to either drop the precision on the CPPlotRange by using CPDoubles or to update the CPPlotRange to a full-blown class with instance variables that are (NSDecimalNumber *). These guys implement the NSCoder protocol, and with a little extra logic, the new CPPlotRange can fit into the codebase nicely.
So that's what I did. It was a blast. I then checked it in and sent Drew an email and updated the issue on Google groups. I asked Drew for comments on the code, and we'll see if he thinks I went overboard on the comments (I didn't), or if there's something he thinks I should have done and didn't do.
All in all - very exciting.