GNOME Bugzilla – Bug 56740
Offering a 'cancel' operation when prompting for what to do with input
Last modified: 2004-12-22 21:47:04 UTC
Hey all, Jody has fixed the simple cases of this bug but wanted a record of the more complex cases. If data is entered into a cell and the user does not press <return>, data can be lost in certain circumstances. (Note the use of "" and <> are simply to denote input and a key, respectively.) Simple case (should have been fixed by Jody) 1) C3 gets "hello" w/o <return> 2) click on G4 -> data is entered into cell if 2) click on column "I" -> data is lost Case with incorrect formula and excel behaviour 1) C3 gets "=sum(A1:A3" [sic] w/o <return> 2) click on a column header -> excel simply closes the parenthesis, we lose the data 1) C3 gets "=sum(A1:A" [sic] w/o <return> 2) click on column header --> excel closes the parenthesis which causes the displayed value to become "#NAME?" Excel case where a cell has been limited to allow only certain values 1) Select C3 2) Through Tools?->Validation, limit the range of values allowed to be greater than 10. 3) C3 gets 9 w/o <return> 4) click on a column header --> excel give an error dialog that looks like the following: *********************************************************************** * Microsoft Excel * * X The value you have entered is not valid. * A user has restricted values that can be entered into this cell * * RETRY CANCEL * ************************************************************************ Where RETRY and CANCEL are both buttons. If CANCEL is pressed, the imput is removed. If RETRY is pressed, the whole cell is selected (black)and the cursor is a large cross and if a mouse click is made on a header, the dialog re-appears. If the entry cell in the toolbar, the same cycle persists except that the cell C# is nolonger highlighted but the entry cell is instead. if 4) File->Quit --> the same dialog appears. if CANCEL is pressed, the input is removed, another dialog appears *********************************** * * * Bubble Cannot Quit * * i * * icon * * OK * *********************************** (the bubble icon is a cartoon speach bubble with an "i" in it.) click on ok, puts you back in the sheet if RETRY is pressed, the same dialog appears and after clicking on <OK> excel puts itself in the same state as when clicking on RETRY in the earlier case. Hope this all makes sense, if you have questions play with excel or contact me. The idea is that a user, having entered information into a cell, should be able to do ANYTHING else and expect that information to stay in the cell or to have an error dialog thrown in her face. (I lost a whole lot of data this way when I built a large gnumeric sheet. To fix it will take as much work as the original input.) Thanks for the cool work, adrian
An additional case to consider: Entry w/o return then File -> save If information is entered into a cell and the user goes to save, the user expects that information to be saved as well. If the user has not hit <return> however, the last input is not saved. 0) new gnumeric 1) d5 gets "123" <enter> 2) e4 gets "another entry" w/o <enter> 3) File -> save gnumeric does not save "another entry" If the user then quits we do get the dialog "sheet has unsaved entries" and if we click the [save] button, the cell content "another entry" is then actually saved! Different conventions are at work from different parts of the spreasheet. This is true also if 3) File -> Save As (text) Note that I have returned to the 0.64 mandrake rpm since 0.65-1 seems to have a broken text exporter.
1) Simple case is fixed indeed. 2) The incorrect formula now works like excel, however the second example will pop-up an error with Gnumeric, this was done intentionally :-) 3) Validation is a feature that Gnumeric does not yet have, however there has been work towards this. 4) I like the idea of having a dialog from which you can also cancel (equivalent to pressing ESC after typing something in a cell and not finishing). I'll try to implement that. 5) The File->Save case has been fixed (it simply will pop-up an error, or accept the expression). Keeping this open for (4)
The approach we've opted for with #4 was Re-Edit Accept The former takes you back to the edit line The latter stores the result (if valid) as a string. You can always undo to cancel.