Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
This post is similar to this post Advanced Expressions as Variables, but since it is a old post from 2018, I thought it warrants a new thread.
My issue is that when using variable with parameter, it seems that if we the variable is expecting more than 10 arguments and you pass less than 10 arguments, the 10th argument looks a little weird. Attaching a sample to show the issue.
Script used is a simple master calendar script
LET varMinDate = Num(MakeDate(2019, 1, 1));
LET varMaxDate = Num(Today());
MasterCalendar:
LOAD TempDate AS OrderDate,
week(TempDate) As Week,
Year(TempDate) As Year,
Month(TempDate) As Month,
Day(TempDate) As Day,
YeartoDate(TempDate)*-1 as CurYTDFlag,
YeartoDate(TempDate,-1)*-1 as LastYTDFlag,
inyear(TempDate, Monthstart($(varMaxDate)),-1) as RC12,
date(monthstart(TempDate), 'MMM-YYYY') as MonthYear,
Week(weekstart(TempDate)) & '-' & WeekYear(TempDate) as WeekYear,
WeekDay(TempDate) as WeekDay;
LOAD $(varMinDate) + Iterno()-1 As Num,
Date($(varMinDate) + IterNo() - 1) as TempDate
AutoGenerate 1
While $(varMinDate) + IterNo() -1 <= $(varMaxDate);
I create a simple variables like this
Sum({<[$1], [$2], [$3], [$4], [$5], [$6], [$7], [$8], [$9], [$10]>} 1)
Now when I use it like this in a chart
$(vVar(Day, Month))
I see this
Notice how the 10th argument is just first argument plus a 0 at the end. Now this is not a problem when I pass 10 arguments like this
$(vVar(Day, Month, CurYTDFlag, LastYTDFlag, MonthYear, OrderDate, RC12, Week, WeekDay, WeekYear))
Now this is what I see
Seems like a bug to me, but I wanted to see if somebody has a better work around then passing blank values like this
$(vVar(Day, Month, , , , , , , , ))
@tresesco do you have any idea?
Hi @sunny_talwar , Thanks for tagging me.
It should be notified as a bug. However, I am not really sure, if this could be fixed that easily from dev team's perspective at Qlik. And why I think so is - I guess the semantics is being used at the back for this parameterized variable is kind of string replacement. Though this is entirely my guess; I don't know the actual design logic.
I guess I can explain what is happening here. Two-digit dollar parameters are actually being broken down, i.e. - $10 is being treated as '$1' +'0' (as I told it's string replacement). You passed 'Day' as $1 (the first argument), and eventually it becomes 'Day'+'0' ='Day0'. If you try any two-digit (or for that matter any number of multi-digit) parameter, you would be able to evaluate with same logic and match the result.
I couldn't think of a workaround though. I was thinking of passing values in some other number system, like hex, and then making it evaluated to your desired two-digit num, but couldn't make it realized.🙁
I guess I can explain what is happening here. Two-digit dollar parameters are actually being broken down, i.e. - $10 is being treated as '$1' +'0' (as I told it's string replacement). You passed 'Day' as $1 (the first argument), and eventually it becomes 'Day'+'0' ='Day0'.
This make sense, but when 10 values are supplied, it is smart enough to pick the 10th argument passed for the 10th $10. It is only when less then 10 arguments passed that it uses 1st argument with a 0 for $10.
May be @hic can take a look and share his opinion on this.
I could confirm this behaviour but I'm not sure if I want to call it directly a bug. In each case the help should be more detailed as it is in regard how it worked as well as with examples and recommendations (means the comma-topic, possible quotes-handlings/requirements, empty and NULL parameter should be mentioned as well as the recommendation to keep the number of parameters low and to avoid any nesting of variables - because even if it's all technically possible it adds an amount of complexity which goes in the opposite direction as the aim of variables which is simplification).
In many tools/logics there is the possibility to add parameter to subs/functions/variables and and quite usually there are 0 - 3 parameter mandatory and n parameter are optional. How should the tool now know which entry from the call should be which parameter in the called routine? It couldn't. Therefore it needs some rules how the parameter are listed. The simplest seems to be just to enumerate them which requires that they are appropriated separated. IMO it's a simple rule and could be easily applied.
- Marcus
Had a quick look in the defect system, not much luck trying to track anything down, so I would recommend submitting this since you have all the details etc. and let us submit it to the engineers to get official response as to determination. I honestly have no idea how this one may go though.
Regards,
Brett