I'm finding that when I use a literal value (like 31, for example) as the parameter to a user-defined subroutine, that literal becomes listed in the Variable Overview as a variable that has the literal as both the variable name an value.
Hence, in the attached sample, you'll find I've defined a trivial subroutine TraceValue and invoked it with the parameter value 31. On reloading (in QV Developer 10 SR3), Settings > Variable Overview show 31 as both Variable Name and Value.
Does anyone else get this behaviour? Is there something I'm not understanding about correct use of QlikView subroutines? I'd have thought calling a sub with a literal to be pretty elementary, and am surprised by this side-effect!
I have found a workaround: change the literal parameter into an expression (e.g. use "57+0" instead of "57" - again, see the attached QVW). But this is, of course, a bit clumsy!
I think your 2nd variant - parenthesising the value - gets the prize for the most elegant workaround, Ralf, with the added bonus that it would also be the best-performing option, since it incurs no arithmetic or conversion operations. Very nice.
I'm feeling that this discussion has run its course - and have thoroughly enjoyed interacting with you all, I might add - and would like to pull-together some conclusions.
A. I think we're all agreed that it's a bona fide defect that Qlikview is turning numeric constants into variables when provided as subroutine parameters, especially since the Reference Manual is pretty clear that this shouldn't be an expected result.
Am I right in reading we're agreeing on this?
B. The cleanest, best-performing workaround is to put such constants in parentheses.
C. It's up to QlikTech how they resolve this, of course, but it seems like the platform needs to have a token-interpretation rule that interprets tokens that look like numeric constants as numeric constants, unless the linguistic context requires a variable name. This should provide satisfactory backward-compatibility for coding techniques that use implicit variable creation in the context of value-passback in subroutine calls, since surely no-one in their right mind would want to use this technique using a sequence of only digits as the variable name.
D. We've discussed a few language philosophy issues, which I'll name for completeness, but these clearly won't be resolved in this thread: desireability of implicit variable creation; consistency of parameter treatment between user-defined subroutines, built-in subroutines and built-in functions; flexibility of variable-name rules.
