Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Description
Graham Perrin
2009-02-07 18:40:25 UTC
Created attachment 60004 [details]
the word minim is selected in the input line but _not selected_ in the corresponding cell
Created attachment 60005 [details]
the overtype in the input line is _not reflected_ in the corresponding cell
Created attachment 60006 [details]
return key moves to the next cell and _loses the user's edit_
Created attachment 60007 [details]
an example of a properly reflected selection
Created attachment 60008 [details]
the word amet is selected in the input line but _not selected_ in the corresponding cell
Created attachment 60009 [details]
the overtype in the input line is _not reflected_ in the corresponding cell
When the selection in the input line is not reflected in the corresponding cell, * Enter key moves to the next cell and _loses the user's edit_ Created attachment 60010 [details]
demonstrating that mismatch also occurs without a highlight of the corresponding cell
Created attachment 60011 [details]
demonstrating again that a press of the Enter key loses the user's edition
Created attachment 60015 [details]
Name Box specifies A1; A1 not highlighted; three neighbours highlighted; the word selected in the input line is not selected in A1
Considering this issue 98999 > If selection within input line of Calc is > not reflected within the corresponding cell, > then an entered change is lost alongside issue 99001 > highlight is sometimes lost from > selected column headings and selected row headings I wonder whether OOo is reacting strangely before, during, or after normal use of the command (Apple) key: • in combination with tab key (switching between applications) • in combination with single mouse clicks (non-contiguous selections). Very difficult to reproduce exactly but in my tests this afternoon/evening I do find that more often than not, a selection in the input line is _not_ matched in the corresponding cell (and so, edition is lost). Bug issue 99002: > double-click wrapped text within a cell that has > white space above the text: insertion point is > misplaced beyond the aim of the user's double click Whilst an excess of white space (above wrapped text) may not be visible in examples in this issue 98999 or issue issue 99001, I wonder whether a misinterpretation of the user's aim (the user's single click) is contributory to this issue. |