Created attachment 72968 [details] A code example to reproduce the bug. Problem description: A missing optional argument is treated as a not declared variable. Steps to reproduce: See a code example below. -------------------- Option Explicit Private Sub Do__Error__Optional_argument_is_not_a_variable__Error(Optional ByVal anArgument) Dim aVariable as Single If False Then Dim anArgument as Boolean aVariable=anArgument ' This line produces an error 12, if "option explicit' is used. aVariable=-456 ' This line is executed only if "option explicit' is NOT used. End Sub 'Do__Error__Optional_argument_is_not_a_variable__Error Private Sub Do__Error__Optional_argument_is_not_a_variable__Success(Optional ByVal anArgument) Dim aVariable as Single 'If False Then Dim anArgument as Boolean aVariable=anArgument aVariable=-456 End Sub 'Do__Error__Optional_argument_is_not_a_variable__Success Sub Error__Optional_argument_is_not_a_variable Do__Error__Optional_argument_is_not_a_variable__Success anArgument:=-123 ' This call never produces an error. MsgBox "1: +" Do__Error__Optional_argument_is_not_a_variable__Error anArgument:=-123 ' This call produces an error 12, if "option explicit' is used. MsgBox "2: +" End Sub 'Error__Optional_argument_is_not_a_variable -------------------- Current behavior: An error 12 occurs. Expected behavior: No error occurs. Operating System: Ubuntu Version: 3.5.4 release
Successfully reproduced in version 4.1.0.0.alpha0+
I do not see that it is connected to "optional". You can see the same behavior without "optional". Can you please explain the line Do__Error__Optional_argument_is_not_a_variable__Error anArgument:=-123 I do not find a description about the syntax and semantic. From IDE it seems to produce the same call as Do__Error__Optional_argument_is_not_a_variable__Error(-123) For me it seems to be the question how a conditional dim statement is executed.
Noel - any thoughts about this one?
(In reply to comment #3) > Noel - any thoughts about this one? Its a bug (although it seems obscure and imho low prio) The problem here is to do with 'Option Explicit' but in addition needs this strange conditional Declaration ( that doesn't actually get executed )
Per Noel's Comment updating fields.
Is this strictly a bug? LO (and AOO) provide the isMissing() function that can and should be used before referring to optional parameters. See the discussion here https://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=69197 LO (and AOO) do have a bug in that isMissing() always returns False for string variables whether or not the parameter is present which is inconsistent with the handling of other data types, See my comments on issue 36737 https://bugs.freedesktop.org/show_bug.cgi?id=36737
Definitely a bug. Looking at the source and the tests here and at https://bz.apache.org/ooo/show_bug.cgi?id=116948 it is crystal clear that only the last optional argument is declared at runtime. Is a bug because default values are not available and, even worse, the parameters in the function prototype are not available as variables at runtime so using >1 optional parameter causes runtime errors. Making more than one optional parameter a source of run-time errors == worse than useless. Only real workaround is to not use the broken feature and require all but the last parameter. The idea that the Basic programmer MUST use the IsMissing feature to work around the optional brokenness is weak at best. The fact that IsMissing is and will always be false because of the way it is implemented makes it appalling. Shouting how Basic == 'workarounds required' as in the AOOo forum? Ludicrous. VBA has supported optional parameters with defaulting and IsMissing() for well over a decade. The appropriate recommendation is: always set default values &/or use IsMissing(arg) to ensure that after ALL args are declared by the Basic runtime they are ALL initialized, except where zero is fine. ALL Parameters in ALL sub/function declarations should be available for use as variables within that sub or function. ALL Parameters Always declared in function scope whether or not values have been passed through them or set by default. I agree that this is fairly low priority, but here is a potential use: The IsMissing test allows the function to distinguish between 2,3,4... argument calls. An upgraded function library can then tell if it is being called from old code before the upgrade that obviously didn't know about the optional params. The opt args can control the new doings &/or transmit more output from the new routines. This also allows real time determination of the need for more or less of safety dance, defaulting, workaround, file format change, etc. as is appropriate. e.g.> If Not IsMissing(optArg1) Then '''REM assign to optArg1 only when it was given e.g.> If IsMissing(arg1) Then arg1 = new fancy.new.object '''REM not given one so create one Optional parameters can allow live testing of new stuff in a shared or delivered function library without requiring the more complex primary routines also be updated everywhere before they have been fully tested live. Was working another (unfortunately related) issue, found the defaulting brokenness and remembered this bug. Will patch <strike>both</strike> all three issues soon. Taking assignment.
OK didn't mean to post that last before further review and flame reduction. Sorry all. I would have moderated some of my complaints about discussion elsewhere: one of the strident posters there reported this bug over ten years ago. To be more positive about the issue: Any argument listed in the function should be created at run-time to avoid seemingly false runtime 'var not declared' errors. I think that VBA does it this way: Any optional argument must be given a default value, or a compile time error occurs. With default values in place, all parameters can be declared in the sub/function runtime local scope and all can be given a value, whether or not they are passed in. IsMissing(arg) should return true when an argument is not given in the specific method call that generates the runtime function scope.
Created attachment 113716 [details] Test cases for position of optional parameter I still see no problem with declaration. I can use the optional parameter inside the function, e.g. assign a value to it. There is no declaration missing. The problem is, that the optional parameter only gets the "is missing" mark, when it is the last parameter. In the other cases it gets some erroneous value, so that ismissing() cannot catch it. The attached document contains examples, where functions with optional parameters are called from a spreadsheet. You can use the main method as well. It calls the functions directly.
** 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.0.5 or 5.1.2 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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
** 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.2.7 or 5.3.3 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-20170522
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
Is this bug still being worked on? I just ran into this bug like a race car doing 150 MPH and hitting the wall. What I got is a macro that will open a form based on the event sent by the button. But being a good programmer I also call it from other methods using just a form name, therefore both arguments, the event param and the form name string are both optional. The issue I have is when I call it to open a form by a name string in stead of an event object I am getting an "Object Variable not set" error. I understand this is due to this bug as it is not marking the first argument as missing. This may not be a bug either, I was supprised that all arguments can be optional, most other languages require at least the first argument to be required. At any rate if it is a bug I would love to see it fixed because I hate redundant code. lol Thanks in advance. Here is my method declaration. Sub OpenForm(Optional oEvent as object, Optional sFormName as string) The idea is that it will open a form based on the event that a button click would pass in, or by a name passed directly to it from some other method.
This is a bug - because the first function (Do__Error__Optional_argument_is_not_a_variable__Error) should produce a compile-time error "BASIC syntax error. Variable a already defined." on line "If False Then Dim anArgument as Boolean". An argument declaration is the same as Dim; and that should be treated the same as sub Dim2(arg As Boolean) if (arg) Then Dim a else Dim a end if end sub
(In reply to Rowland from comment #13) The problem you see is most likely unrelated to this, and is just a wrong usage of optional arguments (which should be treated specifically in blocks like "If (IsMissing(oEvent)) Then ...") To solve your issues, ask a question on ask.libreoffice.org - and note that the method body would be needed, not only method signature.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/840c3a662012c77b5972c869587acd15ee5a3f03 tdf#59327: DIM should fail in procedures when same-name argument is present It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0ed214fd8f64eca4f3192b1646595500d772b243 tdf#59327: two arguments with the same name is an error It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/bcfe36586c6bd07cef3c2ba39abd38bc9b6ab097 tdf#59327: DIM should fail in procedures when same-name argument is present It will be available in 6.4.0.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/9e28127116e35797d373d7d147628a222c7f6ad6 tdf#59327: two arguments with the same name is an error It will be available in 6.4.0.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.