Created attachment 174647 [details] Example When double clicking a cell to directly edit the formula is acting upon a cell where the format is "right justified" and the length of the formula is sufficient to force it to display "on top of" the cell(s) to its left then attempting to place the cursor on any element of the formula which is displayed "covering" the adjacent cell results in the formula being "write protected". The workaround is to edit the formula in the toolbar. Worksheet attached. 1 Try editing any right justified formula by "double clicking" the cell and placing the cursor as defined above. Try editing any left justified formula by "double clicking" the cell and placing the cursor as defined above. Try editing the third formula column (G) which overlaps another formula rather than a data cell and the attempt to locate the cursor in an overlapped portion of the formula results in the cell address being inserted into the formula at that location.
Apologies, I entered the bug report from a different route and was only presented with minimum fields to complete. I hope the description and attachment are sufficiently explanatory Here's the rest😎 Version: 7.2.0.4 (x64) / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: sv-SE (en_GB); UI: en-GB Calc: threaded
Further testing by varying the location of the first attempted insert into the formula produces different results if a first attempt is to insert within the cell boundaries of the formula - the text at that location can be selected and edited but if you change your mind and then move the cursor to an "overlap" location it again inserts a cell address.
I believe the importance should be changed to MAJOR because anything that corrupts even the simplest formula at entry is far more serious than a NORMAL - it may even be deemed CRITICAL. Personally, I can't imagine it would ever have been released in a commercial environment, but if it had, then it would undoubtedly be recalled immediately. Entering a formula for the first time without ever having committed it and then upon "reviewing" the formula, an error is noticed, with any attempt to relocate the cursor (insert point) to the offending location resulting in the instant corruption of the attempted formula should not be "on the back burner". It's bad enough when editing an existing formula but having primary input corrupted at the whim of the software is considerably more infuriating. On some occasions, it can be identified that it's picking up the "background chatter" but on other occasions, it produces "blanks, complemented with squiggly red misspelling underlines from autocorrect" - generally referred to as garbage. It is making any entry of a formula that exceeds the current width of the column seriously tedious. Confession: I attempted to change the condition myself but was informed that one of the big boys will have to read my diatribe before it can be amended. Consequently, the diatribe is reflecting the level of frustration.
I can't reproduce it in Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: ac34bafb6cad056f843ff3ff0dee293bf1e18c56 CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Nor in Version: 7.2.0.4 (x86) / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win Locale: ar-DZ (es_ES); UI: es-ES Calc: threaded To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and re-test? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
Created attachment 175372 [details] Screen Dumps
(In reply to Xisco Faulí from comment #5) > I have set the bug's status to 'NEEDINFO'. Please change it back to > 'UNCONFIRMED' if the issue is still present Version: 7.2.1.2 (x64) / LibreOffice Community Build ID: 87b77fad49947c1441b67c559c339af8f3517e22 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: default; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded In safe mode no change. Are you certain you are trying to edit anything in E4:E9 by double clicking the cell and then in the "live, editable" formula, moving your cursor insert point to anything covering range B:D of the same line? For the avoidance of doubt, view the attached images 1,2,3,4 in ScreenDump.zip In all honesty, I'm not convinced even the most corrupt profile on the planet could consistently replicate this for only right-justified cells when the formula overlaps the cell contents to the left of that cell. Perhaps you could educate me. Double-clicking and editing anything in column F is great but G goes rogue again.
Created attachment 176230 [details] Graphic demonstration of the editing problem I hope the attached .mkv will clearly demonstrate the issue I'm obviously poorly defining. I've made the original screen dumps obsolete as this is a far better demonstration medium. For the record, it's now Version: 7.2.2.2 (x64) / LibreOffice Community Build ID: 02b2acce88a210515b4a5bb2e46cbfb63fe97d56 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: sv-SE (en_GB); UI: en-GB Calc: threaded
@Xisco Fauli Is there anything more I need to do to demonstrate the bug. I only demonstrated one of the effects with the video which hopefully help clarify what I'm reporting and set you on the right path to assess the other statements in the report. I can of course record everything I reported if that would assist.
(In reply to Colin from comment #7) > (In reply to Xisco Faulí from comment #5) > > > I have set the bug's status to 'NEEDINFO'. Please change it back to > > 'UNCONFIRMED' if the issue is still present > > Version: 7.2.1.2 (x64) / LibreOffice Community ... > > Are you certain you are trying to edit anything in E4:E9 by ... Are you sure you not are talking about G4:G9 of your atteached .ods (the right aligned range)? That's the range I'm talking about now. I can confirm the bug with 7.2.1.2 with this description: @Xisco Fauli: Assunme a user wanting to edit a formula *inplace" (after doubleclick its cell or using F2). The user now tries to select a part of the formula with the mouse. IF THIS REQUIRES a click left of the ORIGINAL AREA of the cell, the selection doesn't go to the formulöa string, but to the underlying cell which is inserted this way as a reference in the previous insertion point of the formula. ... The subject may be slightly misleadiong. I would prefer: Editing a formula IN ITS CELL, and trying to select a part of it displayed left of the cell's original area fails. (Yes, this only can occur if the formula cell is horizontally aligned Right, or Center.) In previous versions (just tested with V6.4.5 formulas were treated Standard-Left aligned (like text) during formula editing. Trying to regard the actual current alignment an expectable side-effectz may have been missed.
(In reply to Colin from comment #9) > @Xisco Fauli Is there anything more I need to do to demonstrate the bug. I (I'm not Xisco Fauili, but:) You could abandon irrelevanzt comments like "Personally, I can't imagine it would ever have been released in a commercial environment, but if it had, then it would undoubtedly be recalled immediately." They aren't helpful in this place, and moreover wrong (imo). But if you prefer a "commercial environment" you should move to it. > only demonstrated one of the effects with the video which hopefully help > clarify what I'm reporting and set you on the right path to assess the other > statements in the report. > I can of course record everything I reported if that would assist. NO NO NO. The example sheet is ok. Try, however, to give correct exülanazions (in this case the correct range) when you are talking about your experiences.
(In reply to Wolfgang Jäger from comment #11) > (In reply to Colin from comment #9) > > @Xisco Fauli Is there anything more I need to do to demonstrate the bug. I > > The example sheet is ok. Try, however, to give correct exülanazions (in this > case the correct range) when you are talking about your experiences. If you examine the sheet and all my comments you will understand that BOTH E4:E9 and G4:G9 are right-justified and the error occurs in both clusters. Editing within the bounds of any of these right-justified source cells does not insert the "drill-down" cell address, it only occurs when the edit point is above one of the adjacent cells. Any form of editing in the F4:F9 cluster is successful. When this report is allied with the corruption experienced within bug 145248 it becomes extremely frustrating as there is no user-centric manner of easily editing cells. The major reason for editing cells is normally to remediate discrepancies - most often caused by a lack of experience. My first language is not "spreadsheet technical" so if my definitions offend you I apologise.
There wasn't an "offending definition". I only talked about a misleading range designator. Yesw inspected the example sheet and found the two afflicted ranges E4:E9 and G4:G9. Later I brought your mention of F4:F9 in a wrong context from memory. Sorry.
Hi Colin, Thanks for attaching the screencast. I can reproduce the issue in Version: 7.3.0.0.alpha1+ / LibreOffice Community Build ID: e6968f0485cfb2f6c941d11c438386e14a47095d CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded and Version: 7.3.0.0.alpha1+ / LibreOffice Community Build ID: e6968f0485cfb2f6c941d11c438386e14a47095d CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Also reproduced in Version: 5.2.0.0.alpha0+ Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53 Threads 4; Ver: 5.10; Render: default; Locale: en-US (en_US.UTF-8) and Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
(In reply to Xisco Faulí from comment #15) > Also reproduced in > > Version: 5.2.0.0.alpha0+ > Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53 > Threads 4; Ver: 5.10; Render: default; > > Locale: en-US (en_US.UTF-8) > > and > > Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a) @Xisco Fauli That's a relief, when it didn't reproduce in your first two attempts I was convinced I'd be shot as a heretic ;)). Looking at the range of your tests you must use a shotgun.
(In reply to Xisco Faulí from comment #15) > Also reproduced in > Hi again, Xisco, I've replied to your post as It appears you are the most engaged but it's really only to draw your attention to another point for consideration. I can now appreciate that writing a formula allows a user to simply click on a cell or select a range of cells to insert the address into the formula. In many instances, this could be the desired effect. However, the manner in which it is affecting me is that when I may be trying to re-type a function name or even the address then, as I place the cursor at the desired location, it "drills-down" to the address of the cell above which it is placed - inserting that into the formula. The dichotomy is how to identify and cater for the two possibilities. Does the user want to drill-down for an address or does the user simply wish to re-type? Personally, I would consider that any form of amending in the formula should be considered as re-typing text and perhaps the desire to "capture" a "new" address/range should be indicated by some form of "two key" combination e.g. CTRL+Mouse. Perhaps more advanced users would have an alternate preference. I have also observed that if a cell is double-clicked to signify editing within the cell, the cursor will alternate between a pointing finger and an insert depending upon just where in the formula the mouse pointer is located. The implication is that LO is already aware of the cursor location so perhaps this behaviour is already part of any remedy.