Theo Buis found a bug in the merge pages powertoy.  He lives in the Netherlands and the addin was crashing when he tried to merge pages.  Since "owning" these tools is just as important as creating them - we want to respond to bug reports, questions and even feature requests - we started trying to get a set of steps we could take to always get the crash to occur.  I'll call those set of steps a "repro" since they can be used to reproduce the problem.

 

First, I asked Theo to send me the pages which were giving him the error.  He gave me a couple of pages that generated the error 100% of the time for him.  Nothing special about them - one had text, the other held a screen clipping.  I opened them in OneNote and they failed to merge.

 

When Theo sent me the pages, he included them as attachments to the email.  When I opened them from Outlook, they opened in a read-only state.  I thought about this and couldn't see a way the pages could be merged in this state.  Sure enough, when I tried to repro, the pages would not merge.  Merging needs to create a new page and delete the originals butthe section cannot be altered.  I talked to Jeff about this and he knew it would not work, double checked his addin and made a fix to prevent problems.  He decided to add a dialog reminding users the section was read only (no nothing can be changed). 

 

I sent a copy of the changes to Theo and of course (in a cynical sort of way) they did not fix the crash he was seeing.  This isn't all that unusual.  Many times fixing one bug only exposes another, or trying to track one bug results in finding a different bug entirely.  So we started round 2 of trying to repro the problem.  After a series of emails Theo reported an "Invalid XML" error was appearing.  This started to point us in the right direction. 

 

OneNote's XML schema is published at MSDN.  From a high level point of view, OneNote enforces schema saves against the XSD.  Since ON was being asked to save Invalid XML, Jeff figured his addin was probably not giving the OneNote API the correct format.  The problem was trying to figure out which node or attribute was not in the required format.

 

That got us thinking of differences between Theo's machine (which could repro the problem with every page he had) and ours, which could not reproduce the problem.  Eagle eyed readers will already have spotted the source of the error.

 

Theo uses Dutch language settings.  And since OneNote uses the Windows settings for date format, all his pages were being saved with Dutch date formats.  Once we started testing with this clue, we were able to reproduce the problem with a machine set to use Greek date formats.  And Theo reported that he could merge pages if he set his machine to use English formats.

 

Now Jeff was able to find out what was causing the problem.  English uses a dot character as a decimal separator and Dutch (and Greek) use a comma.  Jeff was trying to convert the XML attribute (which had a comma in it) to a double. 

double currentObjectPos = Convert.ToDouble(objectPos.GetAttribute("y"));

 

Stepping through the debugger showed the comma was being removed, and causing values such as 72.34665439 to be converted to huge values.

 

Since this addin is now needing to work internationally, it must be ready to work with internationally formatted numbers.  The fix is to use an international provider to handle the differing formats.  There is an article on how to do this at  http://msdn2.microsoft.com/en-us/library/9s9ak971.  It's quite a bit of code, so I'll not paste it here.

 

Jeff applied his fix, we tested it (it worked) and sent it to Theo.  He verified it worked for him and I patched the version on the download site.  Bug fixed!

 

Questions, comments, concerns and criticisms always welcome,

John