Setting cell B2's formula (by means of a macro) to =IF(A2="",B1,B2) results in the display in cell B2 Error 508 Clicking on cell B2 shows the formula in the edit box which looks OK. If I then edit the formula by deleting the close parenthesis and pressing enter, the display in cell B2 is as expected (no error). Display of the formula in the edit box is identical to the first display (the close parenthesis is there). Detailed Steps to Reproduce: 1. In new empty LO Spreadsheet document, use the menu Tools>Macros>Organize Macros>LibreOffice Basic... and click on "Untitled 1", then click on the "New" button and then the "OK" button to put you in the macro editor, editing Module 1 of the Standard library of "Untitled 1". 2. Enter the following code in Sub Main: Dim oSheet as Object, oCell as Object oSheet = ThisComponent.Sheets(0) oCell = oSheet.getCellByPosition(1,1) oCell.Formula = "=IF(A2="""",B1,A2)" 3. Execute the code by pressing F5 4. The cell B2 now displays "Error 508". 5. Edit cell B2 to delete the last parenthesis. The error disappears, and the parenthesis is still there when you click on cell B2. Versions: The version I am now running is Fedora's 1:5.1.5.2-1.fc24. However, I first encountered it when running version 4.6 if I remember correctly. When updating to version 5 did not fix the problem, I decided to submit this bug report.
LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 Also tested on: Version: 5.3.0.0.alpha0+ Build ID: fc305bb6d656736bedc2f89789e18d8c9a3bbf2c CPU Threads: 2; OS Version: Linux 3.16; UI Render: default; Locale: en-US (en_US.UTF-8); Calc: group Same behavior on both. Confirming: New Minor - can slow down but will not prevent high quality work; Lowest - macros are not used by the vast majority of users, case in point....this issue has existed for years and no one even reported it.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170901
Version 5.4.1.2 on Windows 7: behavior is unchanged.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Tested version 6.1.0.3 on Windows 7. Still shows same behavior.
Using oCell.Formula = "=IF(A2="""";B1;A2)" instead of oCell.Formula = "=IF(A2="""",B1,A2)" I get no error. Does the interpretation of the separator lie in your locale settings? Can the comma be used as separator?
oCell.Formula takes *standard* (language-independent) syntax of formulas (using ';' for function argument separators, among other things), so "=IF(A2="",B1,B2)" is of course an invalid input resulting in error from parsing the formula text. This is not a bug.
(In reply to Mike Kaganski from comment #7) > oCell.Formula takes *standard* (language-independent) syntax of formulas > (using ';' for function argument separators, among other things), so > "=IF(A2="",B1,B2)" is of course an invalid input resulting in error from > parsing the formula text. This is not a bug. Where does is state that using ';' for function argument separators is standard? LO itself acknowledges that the comma is standard, in two ways: 1. When entering a formula from the keyboard, LO shows a template of the function. This template uses commas, not semicolons. 2. When a formula is created by a macro, using semicolons results in no error but clicking on the cell shows that the formula now in the cell uses commas. My point: this bug, while trivial for experienced LO macro writers, can give new users a bad impression of LO's overall quality.
(In reply to ghborrmann from comment #8) Calc displays formulas to users using whatever modification options set in the program - taking into account the localized defaults for locales (like commas as argument separators in en-US), and user overrides in Options->Calc->Formula. It would use R1C1 notation, or Excel A1 notation, if user sets so. And that's all just a *display* thing; internally, there's only one "API" syntax that is accepted by oCell.Formula - namely, those defined in ODF standard (e.g., for function parameters, see its OpenFormula sect. 5.6 [1]). In other words, answering to > Where does is state that using ';' for function argument separators is standard? the answer is: in ODF international standard. Using locale-independent strings when programming is essential for any programmer, to avoid gotchas when your program stops working on your neighbor just because they changed their display preferences. [1] http://docs.oasis-open.org/office/OpenDocument/v1.3/OpenDocument-v1.3-part4-formula.html#FunctionsFunctionsParameters
(In reply to Mike Kaganski from comment #9) > > the answer is: in ODF international standard. Using locale-independent > strings when programming is essential for any programmer, to avoid gotchas > when your program stops working on your neighbor just because they changed > their display preferences. > I see your point. Nevertheless, the way LO treats the comma-separated arguments leads me to believe that the original programmers intended to accept commas as separators. In any event, the question is moot: the current maintainers apparently consider this issue too trivial to warrant any change.
(In reply to ghborrmann from comment #10) > I see your point. Nevertheless, the way LO treats the comma-separated > arguments leads me to believe that the original programmers intended to > accept commas as separators. Try changing your locale to e.g. ru-RU, and you would get a different belief: that "original programmers" intended to only accept semicolons as argument separators, commas as decimal separators, and that there's no "VLOOKUP" function, but instead "ВПР". What you see is *not* an indication of any "programmers' intention", but a result of localization effort, allowing people to use familiar UI, similar to that of related localized Excel. It is unrelated to API, where programmer uses techniques that are as much as possible generic.