Created attachment 42628 [details]
Pls see original report
Found this with "LibreOffice 3.3.0 RC4 - WIN7 Home Premium (64bit) German UI [OOO330m19 (build 6 / tag 22.214.171.124)]"
Steps to reproduce:
1. open attached "sampleEn.ods"
2. click into 'B2'
3. start spell check
4. at first unknown word press "ignore"
expected: spell check will ignore word and continue
actual: as expected
Now the problem:
10. terminate spell check
11. select 'B2:B9' using mouse
12. F7 for spell check
13. If spellcheck finds an unknown (wrong written) word, press "Ignore"
expected: check should be continued
actual: cell will be checked again and again and again …
LibreOffice 3.3.0, OOO330m19 (Build:6), tag libreoffice-126.96.36.199 Suse 11.0
If I press Ignore I get as you state. If I press ignore all it steps from one mistake to the next.
To get the spell check to start I need to press resume after F7.
NEW due to Steve Edmonds. I still see all details of the problem with "LibreOffice 3.3.2RC1 – WIN7 Home Premium (64bit) German UI [OOO330m19 (Build:201 / tag 188.8.131.52)]"
I saw your activity in several Linguistic Component related bugs, pls. feel free to reassign if it's not your area.
Created attachment 47988 [details]
I see a bit of a nest of horrors around calc selections. The fundamental intent of the dialog seems clear however:
a) The spellchecking dialog isn't modal, so you can swap from the spell-checking dialog back to the document and back to the dialog.
b) If you were spellchecking a selection, and changed the selection while the dialog is open and return to it, it wants to change state to "resume" to indicate that you have to spell-check the new selection from scratch.
When the spellcheck dialog initalizes, it uses ScSelectionState to get the original selection, and it gets a new ScSelectionState when it gains focus and checks if their GetSheetSelections differ to determine if the selection changed, in order to know that spellchecking may need to be restarted, which seems reasonable.
Unfortunately if you launch the spell-checker dialog it activates an editview, which it uses to traverse the cells being spellchecked, and so ScSelectionState once the dialog is first initialized returns this editview as the active selection, i.e. see ScSelectionState::ScSelectionState so the act of opening the spellchecker changes the selection as far as ScSelectionState is concerned.
Its not massively clear to me how the calc selections are expected to work, but my thinking is that GetMarkData is an apparently reliable sane layer, and taking a FillRangeListWithMarks from that to use as the comparison that the selection has changed avoids the problem, and apparently works for me.
oky doky, committed to master. Will be in >= 3.5 I guess.