Description: Version: 7.0.4.2 (x64) Build ID: dcf040e67528d9187c66b2379df5ea4407429775 CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Prior to this release: Enter 01/4 ( and 01/2 and 01/8 specifically) and then backspace to get rid of the leading 0 then press enter would produce 1/4 (and 1/2 and 1/8 specificially) as text in the cell. Now, this release produces a date whether the entry is '01/4 or 01/4 or ... . The only recourse or work around is to use an existing blank cell in the spread sheet to enter the 01/4 as above press enter then cut the 1/4 from the cell and past it into the new row created after updated to this 7.0.4.2 version. THEN sometimes the entry whether 1/4 (one slash four) or '1/4 produces a fraction and NOT the text characters of one slash four. Steps to Reproduce: 1. The preceding entry(s) are 0/ 1/4 becomes a fraction (not what is wanted) 2. enter 01/4 into cell of spreadsheet on new row or a row not created previously 3. delete the leading zero and press return 4. this cell becomes a date field and sometimes a fraction Actual Results: 01/4, '01/4, etc. becomes the date 1/4/2021 and sometimes the fraction 1/4. I am never sure how the spreadsheet cell or the cell in a row will be handled. Sometimes I get lucky though not often when I enter 01/4 I get 1/4 after removing the leading zero. (the same is true for 1/4, 1/2, 1/8 specifically). Expected Results: 1/4 not the fraction just the number four, the slash, and the number four as text in a text cell. Reproducible: Always User Profile Reset: Yes Additional Info: on entering 1/4 in a text field the result should be 1/4 NO Clue at this moment how to check for OpenGL enabled or not. I would have thought such information would have been in the about information if it is of importance. The Help->About again ... Version: 7.0.4.2 (x64) Build ID: dcf040e67528d9187c66b2379df5ea4407429775 CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
This is caused by Tools -> AutoCorrect Options...-> Tab: Replace. There are entries in the replacement table ":1/2:",":1/3:",":1/4:",":1/8"; and further down "1/2","1/4" and "3/4". In addition there are locales having "M/D" or "D/M" as a date acceptance pattern in Tools -> Options -> Language Settings -> Languages -> Option: Date acceptance pattern. So there are 3 situations: 1) Input matches entry in replacement table -> fraction glyph appears 2) Input matches date acceptance pattern -> date is shown 3) Input doesn't match any of 1) or 2) -> text is shown Solutions: 1) Change date acceptance pattern, if regularly using fraction as pure text 2) Prepend input with single quotation mark "'" i.e enter '1/9 for text 3) Remove entries from replacement table (fixes only situation 1)) From my perspective not a bug.
(In reply to Uwe Auer from comment #1) > This is caused by Tools -> AutoCorrect Options...-> Tab: Replace. There are > entries in the replacement table ":1/2:",":1/3:",":1/4:",":1/8"; and further > down "1/2","1/4" and "3/4". In addition there are locales having "M/D" or > "D/M" as a date acceptance pattern in Tools -> Options -> Language Settings > -> Languages -> Option: Date acceptance pattern. So there are 3 situations: > > 1) Input matches entry in replacement table -> fraction glyph appears > 2) Input matches date acceptance pattern -> date is shown > 3) Input doesn't match any of 1) or 2) -> text is shown > > Solutions: > > 1) Change date acceptance pattern, if regularly using fraction as pure text > 2) Prepend input with single quotation mark "'" i.e enter '1/9 for text > 3) Remove entries from replacement table (fixes only situation 1)) > > > From my perspective not a bug. The note about the "glyph appears" for the specific instances like 1/4, 1/2 at my end is true in "ALL" cases to include prepend these specific instances with the apostrophe, e.g. '1/4 should be the text three characters of a 1 a slash and a four. However, that is not what happens. I get the fraction glyph which has not be the case prior to the update referenced. Prior to this update I could enter 01/4 or 01/8 or 01/2 specifically and get the text not the fraction glyph. Now, no matter what I do, I get the glyph 99 44/100% of the time but not always. Today I re-attempted to use the '1/4 and got the glyph. It seems the apostrophe for text is being ignored which I believe it should not be ignored hence the bug report. I did try '01/4 and unfortunately the result was not consistent but I did get '01/4 NOTE: the apostrophe remained visible which I do not think it should. For the example used above, '1/9 it has always worked infact the apostrophe is not necessary in a text cell. '1/4 and 1/2 and 1/8 in a text field even with the leading apostrophe, e.g., '1/4 produces the glyph fraction and NOT the desired three characters of one, slash, and four. Hope this shows why I believe this concern to be a BuG! Thank you your interest and the information you provided for me to try different ways to work with this situation so that I can have the data entry work as desired in the spread sheet. I will be giving a go at some of the other possibilities mentioned to attempt to learn if they will negatively impact our work flow.
I tested with cells formatted as English (USA) and the proper workflow seems to be 1. Tools - AutoCorrect Options [English (USA)] - Options: uncheck "Use replacement table" 2. Leading apostrophe now avoids the text being turned into a fraction Closing.