Problem with Hunspell and 'Nonrestorable'

[wjstarck]

I'm having a problem with the dictionary and the word 'Nonrestorable'.

The non-capitalized word 'nonrestorable' has already been added. Why does the red squiggly line appear below the capitalized version?



If I go into another patient's note and type it capitalized, no red squiggly line appears,



but if I look at another patient where the word was typed (after manually editing the default saved note for a procedure) the red squiggle will be there.



???

[jsalmon]

The custom dictionary is case sensitive. Just add the capitalized version.

If I go into another patient's note and type it capitalized, no red squiggly line appears,

I don't really believe this. I would believe it if you said "I go into a patient's note where I typed it in before (meaning you didn't JUST type it in) and no red line appears".
The red lines won't show up until you edit something in the box. Ergo, are the person making the note thus need your spelling checked. It's annoying to have all the red lines show up when you just want to read a note.
Thus, I have an extremely hard time believing it didn't underline the misspelled word after you typed it out.

[wjstarck]

The red lines won't show up until you edit something in the box.

But they do

I manually added 'Nonrestorable' to the dictionary at Setup > Spell Check. Then I reopened that note, and 'Nonrestorable' had a red line under it. So I typed it again as you can see. Same red line.



But then if I go to the completed procedure note for extraction of #8 on this same patient, and type 'Nonrestorable', there's no red line this time. And if I close and reopen that procnote, no red line shows. But the other one still does.



So I am completely baffled. It's not a huge deal, more annoying than anything.

[jsalmon]

I see what's going on. It wasn't auto spell checking for me because my note didn't have a scroll bar. We have a listener on the text box that fires the spell checking after a user scrolls (that I assumed was impossible to hit without manually scrolling). That scroll event is getting fired when the scroll bar moves to the bottom of the text box (end of the note) when the form loads.

It's still misspelled for your other patient, their note just isn't big enough to automatically fire the spell check event.

[wjstarck]

Wow, OK, great detective work thanks.

[jsalmon]

The real reason the scroll gets fired is because we programmatically act like we're a user scrolling by using the following code found in FormProcEdit.FillControlsOnStartup() around line 2780 in the head:

Code: Select all

textNotes.Select(textNotes.Text.Length,0);

[Justin Shafer]

Neat!

[wjstarck]

OK, Hunspell is still hating on the word 'Nonrestorable'. Doesn't seem to matter where it is in the note. If I stick the word 'Nonfunctional' in place of one of the 'Nonrestorable' s it doesn't underline it:



I don't see how the programmatic scrolling would have any affect on one particular word, especially since it ignores 'Nonfunctional' ???

[jsalmon]

The custom dictionary is case sensitive. Just add the capitalized version.

I added Nonrestorable to my dictionary and it no longer underlines it.

I don't see how the programmatic scrolling would have any affect on one particular word...

You misunderstand. Programmatic scrolling has absolutely no affect on words in particular. It does however have an affect on the red squiggly lines showing up in the first place.
E.g. a note with the word Nonrestorable (when not added to your custom dictionary) that is short enough to NOT require a scroll bar within the Notes box of the procedure edit window will NEVER underline the word in red until focus has been given to the Notes box. However, make the note long enough to where a scrollbar is needed and when you launch the procedure edit window, BAM, it will be underlined by default. I was simply explaining that phenomena which is due to programmatic scrolling which triggers the spellchecker to underline words.