I'm not sure I understand your question.
Right now, the auto-spell code adds squiggles to each block in response to
typing and/or timer events. Once a squiggle exists, it hangs off the block,
where:
- the draw code can use it to draw the squiggle
- the mouse code can use it to raise a context menu
To turn them off, you have two alternatives:
1. Purge them from each block (so they no longer exist) by walking the
document and calling _purgeSquiggles(). For an example of walking blocks in
FV_View, see the new cmdContextAdd(), etc. at the bottom of the file.
2. Continue to let the squiggles exist, but make sure the draw and mouse
code can ignore them when needed.
I haven't thought through the design implications of each.
You may want to confer with Justin before making your choice. Specifically,
I'm not sure how he wants to turn off a single squiggle when you press the
Ignore button in the dialog.
At 06:29 PM 10/20/99 -0500, Stephen Hack wrote:
>I'm planning on adding another pref, Hiding speling errors in doc. This will
>allow the checker to continually check the document while at the same time,
>but not show the ugly red lines. Word reports spelling errors through a
>statusbar icon of a check/X over an icon of a page.
Hmm. You mean they slow down editing to do the check, and then don't show
the results except via that icon? (Sounds like strategy #2 above.)
This would make a decent way to keep track of which individual misspellings
got ignored, though -- add a bIgnore flag to pPOB, and be sure to honor it.
If you can keep an ignored squiggle attached to that word, then it can stay
ignored as far as the user's concerned.
Paul
PS: This reminds me that we need to finish that old rewrite of the
autospell code so that it just checks dirty words in response to editing,
instead of doing the full destructive block-level recheck for each atomic
edit.