Description: Missing or omitted expressions arguments - of Choose() method - are not properly caught. Steps to Reproduce: Consider the following routine: Sub demo Print Choose(), Print Choose(5) MsgBox Choose(2, "a",, 15) ' Should raise Error #13 as in VBA End Sub Actual Results: 1. 1st Print statement raises error #5 2. 2nd Print statement raises error #13 3. MsgBox statement displays "Error 448" Expected Results: Using VBA, results are different: 1. is rejected by VBA compiler 2. raises error #94 3. raises error #13 Reproducible: Always User Profile Reset: No Additional Info: VBA Choose() function doc: https://docs.microsoft.com/en-us/office/vba/Language/Reference/User-Interface-Help/choose-function
I do not quite see, which is the *expected* result - hence, I fail to see what exactly is considered wrong. (In reply to Alain Romedenne from comment #0) > Expected Results: > Using VBA, results are different: Is the "Using VBA, results are different" the whole essence of the report? Then it looks NOTABUG to me: there's no definition in language or function *specification* what should be the error code in which situation. Even in VBA mode, we don't generally have the same errors (even compile-time vs runtime!). Additionally, the bug report does not mention if this is a request for a change for the sake of change, or if there is some existing code that fails working when importing from MSO. I suspect that this is only created as part of documentation effort, not motivated by a real user problem. However, *iif* there's not much effort is required to ensure that the errors *in VBA mode* (only!) follow VBA, then it's fine to implement this. However, note the "in VBA mode": the concern about the specific error numbers can only arise when a code is written with specific errors expectation and handling; and this very expectation is applicable to existing StarBasic code; so if we introduce *such* changes just to keep some (which?) existing VBA code working on migration, we definitely must protect our existing users from the same problem.
For comparison: I read many API docs in MSDN. There it is common for functions to *not* specify any specific error codes that the function *may* return in case of error (e.g., it is common to see "On error, the return value is 0. To get extended error information, call GetLastError", without any mapping of input values to error codes - e.g. [1]); or it may choose to document *some* possible error codes for important cases (that actually are needed for reasonable use of the API), and *also allow other codes* (e.g., [2]). IMO, the error codes are *to the greatest possible extent* are implementation detail, which should evolve together with improvements of the IDE. Trying to fix these would make them part of published API, which is binding, and *must be avoided as much as possible*. [1] https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-movefileexw [2] https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-movefiletransacteda
This is an enhancement request to Basic Choose() method in the context of LibO Basic runtime: - Whenever one expression is omitted such as in Sub demo MsgBox Choose(2, "a",, 15) End Sub I suggest to return Null instead of "Error 448". Such return value would match that of 'index' argument when out of boundaries values are given. PS: You may forget VBA compatible behaviour
Alain Romedenne committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/084d84f09882ec35007ad4566247932a30899799 tdf#141474 tdf#148466 Choose function accepts keyword arguments
Hi @Alain, this bug remains as ASSIGNED. Do you plan to keep working on it? If not, please change its status back to NEW.