I finally got a chance to work on teaching Sheet to create a ProtectRecord by default (with protection off) and HSSFSheet how to provide for turning the protection on and off. Before I submit the patch I'd like to run an issue up the flagpole since I don't have enough familiarity with the POI code base and the deveopment community (yet?) to be confident of my patch getting accepted.
I discovered in ProtectRecord that there the getter and setter for the field_1_protect attribute are asymmetrical. The getter returns a short and the setter takes a boolean. The only POI-internal calls to getProtect() are in the toString() and serialize() methods. The short value is needed in at least serialize() method. However, it seems better encapsulation for other clients of getProtect() if it were to return a boolean. This way the use of a short field for the storage representation wouldn't so completely invade the clients of the ProtectRecord. So, I've started out with the following choices: - Change the return type of getProtect() to boolean. - Define field_1_protect == 1 as true and all else false. - Changed the serialize() and toString() methods to access the field_1_protect variable directly rather than use a getter method. Is this going to be OK? A little poking around in other Record classes turned up a couple of other examples. ProtectRev4Record is consistent with ProtectRecord. SaveRecalcRecord is more like what I propose except that the toString() just emits it as a boolean rather than going through Integer.toHexString on the short value. Should I follow the SaveRecalcRecord model completely? Should I bring along ProtectRev4Record while I'm in the neighborhood? Thanks for the advice, Rick --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
