A bug with the powertoy in development
We're polishing the tools I wrote about last time and getting ready to release them next week. The "bug bash" went well. We found some good corner cases to cause some different crashes, got new sets of eyes to provide feedback and generally had a good time. We've been fixing bugs and verifying the fixes this week ("Regression testing"), and making sure our fixes do not introduce any new problems. One of my fixes for the table summation tool did indeed introduce a new problem. Kathy Jacobs, one of our MVPs, was the first to point it out - thanks Kathy!
Kathy saw my entry from Monday and asked to test some of the addins. I sent her the table summation addin. She managed to break it with her first test. Here is one of the tables she used:
1.
Cat |
Dog |
Horse |
1 |
2 |
3 |
Clearly, there are 6 cells in this table. And the result we would expect after summing the values in the columns would be:
1.
Cat |
Dog |
Horse |
1 |
2 |
3 |
1 |
2 |
3 |
But the actual result was:
1.
Cat |
Dog |
Horse |
1 |
2 |
1 |
2 |
3 |
|
And the reason for this error (can you spot it? - Hint: the addin is summing the columns correctly, but not putting the results in the final table as expected) has to do with the internal structure of tables in OneNote.
Looking back at the first table, the 6 cells are obvious. What OneNote does internally is not quite as obvious. Each cell has a separate node (assume it is named "OE") for the contents of each "piece" of data in the cell. Look at this table and maybe this will be more clear:
1.
1 1.1 |
2 |
3 |
4 |
Clearly, there are 4 cells. But internally, OneNote uses 2 nodes to store the 1 and 1.1 in the first cell. So the count of cells in the table is 4, but the number of values (nodes) is 5.
My powertoy had worked properly for table 1-3 above, but failed in table 4 initially. I added a routine to correct for the difference in number of nodes vs. number of cells, and then table 4 (and similar tables) started working as expected. This is the version of the addin Kathy tested.
Without going into my code (although I will post it next week as well), I was adding the last row of blanks correctly, but not adding the expected value to the proper cell, since I was basing everything on a node count instead of the number of cells in the table. Unfortunately this is the version Kathy received, which worked for tables with multiple values in each cell worked (like table 4), but failed for tables 1-3 (the simplest type of table). So right now I'm testing the new, simple method (no more dealing with a variable offset!) to populate the final row of the table. It's looking good and should be done soon.
Questions, comments, concerns and criticisms always welcome,
John