From the (long ago) time I also sometimes used automatic labes I remember the feature behaving (though often erratical) as I told:
The range being assigned automatically was terminated before a blank cell occurred.
This was also the case when I tested today with LibO V6.4.0,2RC, but I had to use the “workaround” {=TRANSPOSE(TRANSPOSE('label1'))} to get the range returned. With {='label1} entered for matrix evaluation I got applied the intersection mode nonetheless, and also having preselected the output range the first element was repeated.
Automatic labels for rows did not work at all.
And no. I will not report a bug about this gimmick ;-).
@Lupp, aka “Wolfgang Jäger”
@Lupp: it was 1-cell range for me, too - but still that was a range (variant(1 to 1, 1 to 1)). And so it doesn’t matter which size the range is: it is passed to user-defined functions as range, not as scalar value.
Yes. This was what I experienced yesterday when automatic row labels worked in an example. I hade made from the “typed screenshot”. I just stumled over the AMJ2 in your comment above.
On my last try now autoamtic row labels worked for me in V6.4.0.2 too.
My AMJ2 was from OP’s variant(1 to 1,1 to 1021), which could be because of some content to the right of discussed range. 
hello @Matvej,
i agree with all proposals for ‘better coding’,
one add. comment, pls. check if hard recalc (strg.-shift-F9) will get results, there are rumors that ‘macro functions’ are excluded from autocalculate if they can’t find their dependencies once thoose are not ‘direct’ references but masked in strings (or behind labels?),
the ‘rumors’:
you may find add. info in bugs.libreoffice.org at #40203, #43003, #54858, #55774, #79588, #81757?, #82610, #129896,
esp. https://bugs.documentfoundation.org/show_bug.cgi?id=79588#c26 made things clear(er) to me,
imho plenty users would like improvements, but it would be a big job in coding?
in the meantime i’d suggest to correct help and manual to give info about this weakness …
This is completely unrelated to the topic. The question is about passing arguments to user-defined functions; your references (written without using the convenient tdf#NNNNNN syntax, that would automatically become hyperlinks, which you could already known by now, having spent enough time on the site) are about how Calc knows which cells depend on which. The latter is just a matter of Calc knowing something is a reference or not; and strings are of course not, so passing a string to any function, Calc does not automatically mark that cell as dependent on anything that the string could possibly mean. Some built-in functions (like INDIRECT) can establish a dependency to cells referenced by text, but that’s only possible to low-level functions. But - again, this question is not about passing strings; passing named ranges does establish the dependency in Calc.
hello @Mike2,
you’re right, it’s another problem - in the same area -
(minimum common: ‘macro functions don’t work as expected’)
with the reference to the ‘vol’ function now given (which was not given at the time of my guessing) i could test, funny results,
-
‘passing named ranges does establish the dependency’, yes, manually set cell labels (named ranges) work correctly, but the OP doesn’t do that,
-
using named ranges in formulas expect them given without quoting,
-
‘automagically found’ labels do not work,
-
they do work for ‘simple’ formulas,
-
they do not work for ‘macro-functions’, at least not in ths case,
-
the formula is aware of and does adopt the automatic ‘label → value’ relation to the extent of changing the reference when the label is changed, but
-
on evaluation: error trying to save another opened sheet and ‚basic runtime error, object variable not set‘
imho that qualifies for filing a bug.
ver: 6.4.0.2
This qualifies for learning things (as usual).
- Calc can reference ranges using different names: A1 syntax; R1C1 syntax (dependent on a setting); named ranges; automatic row/column labels (a special kind of named range). Automatic row/column labels are enclosed in the single quotes (the quotes are added automatically when you enter
a*b*c). So - “but the OP doesn’t do that” is the first false statement (OP does that, using the labels as range names). - “using named ranges in formulas expect them given without quoting” only relates to named ranges managed through
Sheet▸Named Ranges And Expressions. - ‘automagically found’ labels do work as expected, given that they refer to ranges. Trying to use
=VOL(A1:A1;B1:B1;C1:C1)will result in the same result, although this does not use any “automagic” names.
4 : that built-in (and add-in) functions “work” is just because for such functions, their argument type (scalar/range) is known to Calc, and so Calc knows when to use intersection to provide the expected scalar argument. For user functions, Calc doesn’t know the type (see tdf#66717).
5 : they do work for ‘macro-functions’: just programmer needs to account for the mentioned property of user functions. Again - a matter of learning.
7 : what is that about? the question is not about saving other sheets. Trying to multiply arrays of arrays in Basic is an error, so naturally an error on evaluation results.
-
the OP didn’t use manually set named ranges, they would have worked, with the restrictions given under 3.
-
yes, that’s what i was talking about, manually set named ranges, that they are working ok with formula “abc” (opposite to automatically found labels, not working ok, with formula “‘a’‘b’‘c’”, äh, sorry, when used in a macro function),
-
a, b, c, didn’t work for the OP, your sample A1:A1 uses direct adressing, that doesn’t work either, what worked was applying ‘named ranges’ as labels to single cells,
sorry, numbering in previous comment automatically screwed,
4 : can that be improved by better ‘defining’ of the user functions? or by providing an interface which gives the users / macro programmers the ability to define that process?
5 : please be more specific, what could the OP have done better to get the automatically assigned labels to work correctly? providing the arguments with ‘1*’ or ‘0+’? why isn’t calc capable to do such silly things by it’s own while finding assumed labels even on other sheets?
6 : you agree?
7 : on my system calc showed a dialog box: 'error saving file xxxxxxx.yyy, basic runtime error, object variable not set‘ when triggering the macro, on new tests the part reg. file is gone,
8 : tdf#66717 is a nice pice of irritating users by use of ‘randbetween’, i suspected my whole system buggy 
- will play with and try to learn from it in near future …
OMG.
1, 2: Please try to understand the simple thing: the problem is not the “kind” or range you use: be it a named range, or A1-like address, or automatic row/column label. All these are normal Calc ranges, and are treated identically in any place of Calc: it’s not the difference between “named ranges vs automatic labels”, it’s the difference between a single cell like “A1” and a range like “A1:A1”. These are different entities, the former being a cell object, the latter being a range (not a cell object). If you define your named range as A1:A1, it will behave just like automatic label. Stop trying to repeat that “named ranges work; automatic labels don’t” mantra. Simply learn the difference. Where you can fine-control ranges, like in “named ranges”, you can choose between “A1” and “A1:A1”. Where it’s automatic, you need to accept that it uniformly makes anything ranges, be it A1:B1 or A1:A1.
4: did you even try to understand the bug I mentioned (and you referred to in #8)? Or are you discussing without even trying to see what you are being told?
5: OP needed to check types of passed arguments, and do one thing when it’s an array of array of only one element; another if array of multiple elements is passed; and yet other if scalars are passed.
6: agree with “the formula is aware of and does adopt the automatic ‘label → value’ relation to the extent of changing the reference when the label is changed” part? it’s obvious, and as I told, that’s a normal range reference. I don’t understand why should I need to repeat the obvious.
7: “on your system” is something unrelated to the question. Please start another, or file a bug. Enough off-topic from your side without that piece.
8: “randbetween”??? another cryptic part…
just call me b., god is reserved for others,
1 : yes, you’re right, the ‘label finding automatic’ applies the labels to a range! of cells instead of one single cell … i was a little slow to realize this because the example has only one column for values 
thanks for your patience to clarify, hope it will help others as well …
2 : i’m still short how / why the ‘trick’ of applying a calculation (‘0+’ or ‘1*’) to the cell / value is working. is it by doing the selection which cell of the labeled range is to be taken in the formula into the sheet rather than into the called function?
4 :, 8 : yes, i tried, ‘intersection’ made somthing clearer, ‘randbetween’ - used in your! sample there - was quite fun
2: result of an arithmetic operation involving a range is a scalar, with intersection used to obtain operands. That scalar result is passed to the user function, unlike when you pass there the range itself.
8: there was no my! sample (esp. having RANDBETWEEN) neither in the AskLibO question, nor in the bug. The one that had RANDBETWEEN was from Wolfgang Jäger, aka @Lupp. But why did I ask, I should already get used to your “I will write anything without an effort to express myself clear” style.
Hello,
I can see, that a big discussion arose. Please can you point me to some doc / tutorial / wiki, where I can learn more about bacis language used in Libre Office.I fount just a few quick reference “cheatsheets”, but I would like to know more about data types in basic and thier mapping to Calcs objects.
I tried to use something like:
function Vol(a as double , b as double, c as double)
too make Calc to pass arguments as scalars, but apparently this in not the way how it works.
Now I see, that I should check whether passed arguments are scalars or variants, but I do not how to check it, and how to work with variants.
Is there some more advanced tutorial for Calc and it’s cooperation with basic available ?
Is there some wiki for LibreOffice basic ?
I don’t think there’s much beyond Andrew Pitonyak’s great book. A bug that I filed long ago, and that I referenced above, gave me the knowledge that there’s no way (at least till today) to pass Basic functions argument types to Calc, so that it could make better decision what to pass to the function. Currently I take the knowledge about internals from reading the code and debugging.
To detect if an argument is an array, use IsArray. Use LBound/UBound to check the array dimensions’ sizes.
@Mike2,
2 : ok, i’d try to express that in ‘my words’, but - i hope - i understood it right,
8 : once again you’re right, sorry for having overseen this, i don’t like your ‘tone’, but i like when you are right and i can learn from it,
thanks, b.
@newbie-02: I suppose I must apologize now. I feel constantly trolled by you (personally) since the very beginning, when you kept declaring everything I write wrong…; and somehow I started to get offended by, like, everything you write. But that is obviously wrong from my side, and - I apologize. Sorry for my tone.
@Mike2: no problem, and no apologies necessary, LO is not so easy, and it is difficult to switch between a user’s point of view and that of a developer, the first of whom wants to have a program that is easy to understand and functions correctly, and the second of whom has to deal with many constraints of the compiler, hardware, libraries, compatibility with Ex$el, etc. … i just represent the view of a user, with limited knowledge, and you are quite harshly the one programmer who is gradually annoyed by stupid questions and suggestions from users … nevertheless, I think that our ‘arguing’ has helped LO to improve in some little points, and to shed some light … to support the progress of LO it is important to build bridges between the different points of view, to this end we should not throw dirt but try to understand the other side … just like you are annoyed by stupid questions ever again i’m astonished how many problems have been passed on unresolved for how many years …