Once I made my change to my calendar/planner addin to get the columns to size correctly, I needed to test it. I wanted to make sure that my table was usable on different screen resolutions and did not draw off the page.
My test matrix went from 800×600 to 1600×1200. I ignored color depth since this was an equivalence class test, and threw in a test for 120 dots per inch. This went pretty well, and the only thing I noticed was that the columns became small relative to the screen size at the higher resolutions. This is not surprising, but since they were usable, I decided to avoid code to detect screen resolution and try to adjust from that. Any code I would have added would need to be rested at all the different resolutions again, and probably would have been the most fragile bit of code in my addin. I wanted to keep this as simple as possible (and in fact, if you look at my table creation routine, you’ll notice I used string manipulations rather than XML to create the table. There’s a long winded reason for that and I’ll cover it another time).
The "isLocked" attribute which gave me so much trouble before I read the documentation was a little more interesting. I wanted to make sure that any user could resize the columns after I created them. I was worried about that word "Locked." Testing quickly allayed my worries and the columns were resizable at a whim. Now that I think about it, that attribute "isLocked" should probably have been named something like "userModified" to make it more clear what the attribute really means. I do not want to change our XML API, but I will probably have a great theoretical debate with Dan Escapa about naming conventions.
And did you notice the bug in our documentation? Here’s the text for the attribute:
The "isLocked" attribute
By default the widths of columns are unlocked and can be resized as the user types content into a cell. Once the user [h]as sized or resized a column width this attribute is set to true.
I bold faced the errant text. We dropped the letter h from has. This is a great example of a type found far too late to be fixed before shipping (in fact, I did not see this until about 2 years after we shipped the documentation). I’ll file a bug to see if we can get it updated but will set the priority to be low. The text is clear and since any developer will be able to understand the comment, I don’t know if we need to use resources to alter that text or find and fix other problems we face. I’m betting we have more pressing concerns.
And I was feeling pretty happy with my addin when I noticed what David Nimmo created. He came up with a notebook for 2009 which uses a nice image (a la Outlook) for each day, and separated the months into sections. It’s pretty slick and worth the ~13MB download. Be sure to give it a try!
Questions, comments, concerns and criticisms always welcome,