We will be migrating from Ask to Discourse on the first week of August, read the details here

Ask Your Question

Calc, macro: optional parameters of REGEX(), INDEX() functions when calling them via FunctionAccess

asked 2020-01-27 12:39:59 +0200

Lupp gravatar image

updated 2020-01-27 12:46:32 +0200

How can I call REGEX(p1,p2, [omitted], p4) from a macro?

Some explanations may be helpful:
Some standard functions of Calc have optional parameters.
In some cases there is specified a default (or a conditional default) to be used if the paramter is omitted.
Generally the optional parameters are (only one or) assembled in a sequence at the end of the parameter list.

Concerning a few functions a parameter is declared optional though another parameter following in the list not is optional - or is optional but may be charged nontheless even if a previous optional parameter was omitted).

In very few relevant cases now again there is no default for the omitted parameter.
Namely in the cases of INDEX() and REGEX() the omission of such an optional parameter (second in case of INDEX(), third in case of REGEX()) functionally is not truely an omission, but a distinct information which not can be passed to the function putting any explicit value in that place.
The distinct information is:
For REGEX(pText; pSearchString; ; pSpecial): Return the match using pSpecial as ordina (index).
For INDEX(pRangeRef; ; pColumnIndex): Return the whole column as a column-array.
[Now the functionality is respectively the same with omitted pColumnIndex or both index parameters omitted].

Trying to call such a function via FunctionAccess with a distinct omission of an optional parameter I couldn't find a way to charge the parameters Array(). Simply omitting a parameter if there is a subsequent one causes an error. Array(pRangeRef, , pColumnIndex) e.g. first does not broadcast an error but only returns the error value Error 448 for the middle element - which is the best it can do. But the call to INDEX() then using FunctionAccess doesn't evaluate this as intended but throws an error IllegalArgumentException. It's respectively the same with REGEX().

Relief (kind of):
In case if INDEX() there are workarounds, and the problem isn't acute anyway. But in case of REGEX() the functionality is unique and I only found an unreasonably complicated and slightly unsafe workaround. Therefore the question at top.

edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted

answered 2020-01-27 14:00:16 +0200

ScFunctionAccess::callFunction does not create a special value necessary for missing arguments (see ScInterpreter::IsMissing). Worth a report? ;-)

edit flag offensive delete link more


@Mike Kaganski: Thanks for your interest and for your tolerance ;-).
Well, I actually "needed" to call REGEX() for the functionality provided by omitting the third parameter from macros for a little project, but I found a workaround based on specific replacements working well enough though rather complicated.
But generally I would prefer concerned functions would offer a way of saying explicitly"Treat this parameter as omitted.".
Concerning macros again: The Array() function in LibO Basic does it's best passing Error 448 without breaking the execution. FunctionAccess and the accessed function would "simply" need to evaluate this.
Worth a report? Yes. I already drafted one, but... The world is bigger than my desk.
By the way: Did you notice my question concerning "raw bytes"?

Lupp gravatar imageLupp ( 2020-01-27 14:33:42 +0200 )edit

By the way: Did you notice my question concerning "raw bytes"?

Yes. But ... that is impossible from the PoV of high-level language like Basic; and for workarounds like using dynamic-link libraries, it would be non-portable. Without that, using UNO does not change things that Basic is Basic, so... :-)

Mike Kaganski gravatar imageMike Kaganski ( 2020-01-27 15:04:59 +0200 )edit

Comibg back after a while.
Rather different from Basic, Pascal, surely a high-level langage, has the concept: The decalaration clause absolute places a second variable at the same physical position in RAM as the referred one. I often used this (and it's the basis of the working of my dll for manipuilating Double bitwise - do you remeber?).
I may have misunderstood the "that is impossible"?

Lupp gravatar imageLupp ( 2020-07-12 16:28:01 +0200 )edit
Login/Signup to Answer

Question Tools

1 follower


Asked: 2020-01-27 12:39:59 +0200

Seen: 122 times

Last updated: Jan 27 '20