Forum Discussion
OneNote Interop API UpdatePageContent breaks Spell Checking
Using the interop API, IApplication.UpdatePageContent(xml, lastModTime, XMLSchema.xs2013, true)
Given a page with an OE paragraph, where the user selects a run of text, not including the end of the text, and the text contains spelling errors before, within, and after the selection range.
When the proofing language is changed for the selected range, then the spelling errors after that range will no longer be highlighted as errors.
Here is an example text run, before modification, with a selection range. Notice the word "benoyd" is misspelled and would be highlighted by OneNote.
<one:OE alignment="left" quickStyleIndex="1" selected="partial">
<one:T><![CDATA[To ]]></one:T>
<one:T selected="all"><![CDATA[infinity]]></one:T>
<one:T><![CDATA[ and benoyd...]]></one:T>
</one:OE>
And after modification to change the language of the selected range:
<one:OE alignment="left" quickStyleIndex="1">
<one:T><![CDATA[<span
lang=en-US>To </span><span lang=yo>infinity</span><span lang=en-US> and benoyd...</span>]]></one:T>
</one:OE>
But the word "benoyd" is no longer highlighted as misspelled. The user can manually iterate through the text by interactively clicking the Review/Spelling button, causing OneNote to highlight the misspellings.
Alternatively, if the user changes the proofing language of the selected range interactively using the Proofing Language panel, it results in exactly the same XML structure generated by OneNote natively, but OneNote retains the misspelling indicators.
Making exactly the same changes to the XML using the UpdatePageContent API should result in the same behavior as using the UI.
2 Replies
Your XML after UpdatePageContent matches the structure produced by OneNote’s UI, yet spelling indicators after the changed language range disappear until OneNote performs another proofing pass. The Interop API documents page content updates, but it does not promise preservation or recalculation of the editor’s live spell-check state. Replacing the changed Outline can therefore leave the stored language markup correct while the proofing cache is stale. Keep the submitted XML to the smallest changed page-level object and avoid force=true unless the page contains unknown data that must be overwritten. After updating, the safe workaround is to let the user run Spelling or change the proofing language through the UI, which triggers re-evaluation. Test the same minimal page on the latest supported OneNote build using the xs2013 schema. If reproducible, submit the before/after XML and build number to Microsoft. The published Interop interface exposes no method that forces a spell-check recomputation.
I have to be honest, this sounds like an AI reply, restating what I already wrote above. But I think the intent of your message is true and clarifying. The OneMore addin does everything you suggest - minimal page-level object updates, avoiding force=true unless absolutely necessary, etc. Essentially, you're saying, there's no programmatic solution.
