Hello,

I am trying to make the same survey work in both the open-access and closed-access modes, but unfortunately seem to have hit a brick wall.

My survey has a question --let's call it "Salary"-- that I want to be displayed only if the respondent is employed. In open mode, the employment status is determined by an earlier question, "EmpStatus" (possible values: "yes" or "no"). In closed mode, however, the EmpStatus question is hidden, and the information is passed in via a token attribute. (It has to be this way for me because in some situations, the survey is administered to new, unknown participants, and in others, the respondents have already entered their personal information via a prior survey, so I don't want to have them answer the same questions all over again.)

So, my first attempt at the relevance equation for Salary was:

(EmpStatus == "yes" or TOKEN:ATTRIBUTE_4.NAOK == "yes")

where TOKEN:ATTRIBUTE_4.NAOK provides the employment status obtained from an earlier survey.

In closed mode, this works just fine, but in open mode, with TOKEN:ATTRIBUTE_4 undefined, the above equation always evaluates to TRUE, regardless of the value of EmpStatus. The TRUE result is surprising in itself, as errors are normally expected to return FALSE, aren't they? The real problem, though, is that the Expression Manager keeps trying to parse the rest of the equation even after the first test returns FALSE, which results in an unavoidable error.

So, to fix the open mode processing, I took the token attribute test out of the Salary reference equation, leaving it at just (EmpStatus == "yes"), and then tried to make this work for closed mode by adding a hidden Equation-type question at the start of the form setting EmpStatus to the value of the attribute:

{EmpStatus = TOKEN:ATTRIBUTE_4.NAOK}

(This was what I typed into the Equation field in the question definition, and I did check that TOKEN:ATTRIBUTE_4.NAOK was, in fact, defined and had the correct value.)

Now, open mode was working fine, but in closed mode, EmpStatus still remained undefined, despite my attempt to assign it. I imagine the explanation for that has to do with this passage in the manual: "Assignment is done only in PHP. This don't update any value on same page, but only when user move next, previous save" ( www.limesurvey.org/manual/Expression_Man...t_Operator_.28.3D.29 ). If I understand this statement correctly, the assignment will only have an effect if I send the page off and then come back to it via the question index -- is that what it means? If so, it would, of course, be useless for my purposes.

So, I am at the end of my rope here. Isn't there a way to either keep a relevance equation from breaking down completely when one variable is undefined, or else, to assign a value to a question, such that it would be immediately available for relevance testing on the same form?

Please help!

Thanks,
Oleg.

oleggorfinkel wrote: …
So, I am at the end of my rope here. Isn't there a way to either keep a relevance equation from breaking down completely when one variable is undefined, or else, to assign a value to a question, such that it would be immediately available for relevance testing on the same form?…

Hard to do …

In 2.6lts, i use a {TOKEN:ATTRIBUTE_6} in template and test if it's empty or not : it's empty : it's a survey with token and 6 columns (this columns must be empty for token …), else it's a survey without token.

In fact : it's to hide (or not) the index, showing only to telephone interviewer .

I would just add in a hidden single choice list question and then populate that with the punch you need via an equation question... something along the lines of this ...

RespType: Hidden Question with the responses 1) From Token 2) From Open

Equation question :
{RespType =(if TOKEN:ATTRIBUTE_4.NAOK=="Yes",1,2)}

and then use RespType as part of the filter in your question ....

Did you try without the .NAOK ?

So, to fix the open mode processing, I took the token attribute test out of the Salary reference equation, leaving it at just (EmpStatus == "yes"), and then tried to make this work for closed mode by adding a hidden Equation-type question at the start of the form setting EmpStatus to the value of the attribute:

{EmpStatus = TOKEN:ATTRIBUTE_4.NAOK}

Instead of that, try loading another equation question with the token value and reference that in the relevance equation for "Salary".

So, for example, an equation question with code equation1, with this as a value:
And, this for the relevance equation:
You will still get an error in equation1 in the open survey but I don't think that will affect your relevance equation.

tpartner wrote:

So, to fix the open mode processing, I took the token attribute test out of the Salary reference equation, leaving it at just (EmpStatus == "yes"), and then tried to make this work for closed mode by adding a hidden Equation-type question at the start of the form setting EmpStatus to the value of the attribute:

{EmpStatus = TOKEN:ATTRIBUTE_4.NAOK}

Instead of that, try loading another equation question with the token value and reference that in the relevance equation for "Salary".

So, for example, an equation question with code equation1, with this as a value:

Code:

{TOKEN:ATTRIBUTE_4}

And, this for the relevance equation:

Code:

EmpStatus == "yes" OR equation1 == "yes"

You will still get an error in equation1 in the open survey but I don't think that will affect your relevance equation.

This did the trick -- thank you very much for the suggestion, Tony!

The curious thing is that when {TOKEN:ATTRIBUTE_4.NAOK} is used as an equation question value and the token attribute is undefined, the expression actually returns the literal string "TOKEN:ATTRIBUTE_4.NAOK". I find this a surprising design decision for the Expression Manager. My instinct in case of an error like this would be to return an empty string. I would also return FALSE, rather than TRUE, for relevance expressions that hit a fatal error, but when it's only a case of one of the variables being undefined, I'd have it resolve to an empty string and then process the expression accordingly -- that would make for a more intuitive error-handling behavior. These are just my suggestions, but what do you think?

Cheers,
Oleg.

DenisChenu wrote:

Did you try without the .NAOK ?

Thanks for the suggestion, Denis. Yes, I did try that, but it didn't make a difference...

davebostockgmail wrote: I would just add in a hidden single choice list question and then populate that with the punch you need via an equation question... something along the lines of this ...

RespType: Hidden Question with the responses 1) From Token 2) From Open

Equation question :
{RespType =(if TOKEN:ATTRIBUTE_4.NAOK=="Yes",1,2)}

and then use RespType as part of the filter in your question ....

Thanks for the suggestion, Dave, but this was exactly what I tried to do on my first attempt, as described in my original post. Trouble is, any expression that tries to set a non-equation question value doesn't seem to work when one of the variables is undefined. As I mentioned in my reply to Tony, I think that this is not the optimal way to handle such a soft error. Having the undefined value resolve to an empty string would be much preferable, in my view...

oleggorfinkel wrote:

DenisChenu wrote:

Did you try without the .NAOK ?

Thanks for the suggestion, Denis. Yes, I did try that, but it didn't make a difference...

I think it's an issue :

TOKEN:TOKEN.NAOK must send an error : allways

NAOK or shown are always for question, not fixed var : www.limesurvey.org/manual/Expression_Man...#Access_to_Variables

DenisChenu wrote:

I think it's an issue :

TOKEN:TOKEN.NAOK must send an error : allways

NAOK or shown are always for question, not fixed var : www.limesurvey.org/manual/Expression_Man...#Access_to_Variables

Another strange thing is that TOKEN:TOKEN CAN, in fact, be tested in relevance expression logic, and simply returns an empty string when undefined (i.e. when the participant table has not been initialized). TOKEN:ATTRIBUTE_X, however, fails and breaks the whole expression. To me, that doesn't make sense. Wouldn't it be much better if token attributes behaved in the same way as the core token fields and returned an empty string when undefined?

oleggorfinkel wrote: Another strange thing is that TOKEN:TOKEN CAN, in fact, be tested in relevance expression logic, and simply returns an empty string when undefined (i.e. when the participant table has not been initialized). TOKEN:ATTRIBUTE_X, however, fails and breaks the whole expression. To me, that doesn't make sense. …

You can report issue BUT : we create false var for core token (TOKEN, FIRSTNAME etc …) but not for the 255 and more attribute …