Hello everyone,

I am new to LimeSurvey (3.15) and I need your help.

The problem is : I have two dropdown lists with values [0,5,10,...,100] and it appears that some values are not correct in the condition.

On the 1st dropdown (q9), i only choose a value from the list.

On the 2nd dropdown (q911), i have added on Question validation equation (! is_empty(q911.shown) and q911.shown <= q9.shown) but this condition doesn't work with the value 5 when the value of q9 is smaller than 50 ?? The value 100 also doesn't work with the condition ??

I don't understand where the problem is coming from.

I made an open demo, if you want to try and understand better my problem.
demo.limesurvey.org/index.php?r=survey/index&sid=889158&lang=en

What I wanted is to show an error when the value of q911 is greater than the value of q9.

Thanks in advance

You can report the issue.

Workaround :

You can report the issue.

Workaround :

On the 2nd dropdown (q911), i have added on Question validation equation (! is_empty(q911.shown) and q911.shown <= q9.shown) but this condition doesn't work with the value 5 when the value of q9 is smaller than 50 ?? The value 100 also doesn't work with the condition ??

The question is, what do you mean with "it does not work". What do you want it to happen and what is actually happening?

However, 5, 50, 100, those numbers basically tell me that you are comparing a number with a string. basically the string 5 is bigger as 100.

I guess the problem comes from the use of ".shown", use the answer option code by just using the "q911" instead of "q911.shown". Then it should compare an integer with an integer and things should work out.

I adapted this in your demo survey and I got rid of the stupid welcome screen that made testing so much more inconvenient. Have a look if it works now for you.

By the way: The demo is cleaned up regularly, so your link might not work anymore soon.

@DenisChenu:

But is it really an issue? I mean here they are comparing basically strings, aren't they?

Thank you DenisChenu,

The Workaround you told is working great.

Hi holch,

Thanks for your answer.

I just unsderstood that the values in dropdown list are all to be considered as strings. Even if there are only integer values, they must be converted with intval().

For info : I tried using the "q911" instead of "q911.shown" but it is the same result, it is comparing string.

Did you also change q9.shown to q9?

I just unsderstood that the values in dropdown list are all to be considered as strings. Even if there are only integer values, they must be converted with intval().

Yes, because .shown is using the text of the answer option == string. If you use just the answer code, then it is either a string (if you use letters in the answer code) or an integer if you are using only numbers (as you did).

holch wrote: @DenisChenu:

But is it really an issue? I mean here they are comparing basically strings, aren't they?

See mantis issue …

My opinion was : Answer code are string and must be always compared as string, but global opinion : is «if we try to compare 2 numeric string : we compare at number»

See some mantis issue :
bugs.limesurvey.org/view.php?id=8324
bugs.limesurvey.org/view.php?id=7805
bugs.limesurvey.org/view.php?id=8546
…

Then : all of this is fixed in 2.6lts : it work in 2.6lts (but we don't have question validation).

Thanks for answering, Denis! Much appreciated.

My first thought would also for the answer code to compare integer with integer if only numbers used as answer code. But I understand your point.

I think considering all answer codes as string would be theoretically cleaner, but I think it makes things overly complicated in practice. Tricky one.

holch wrote: …
My first thought would also for the answer code to compare integer with integer if only numbers used as answer code. But I understand your point.

Then : you think it's an issue

holch wrote: I think considering all answer codes as string would be theoretically cleaner, but I think it makes things overly complicated in practice. Tricky one.

Excatly : for a logic man : .code is code => it's string, but it's really more easy to compare as number if it can be number .

No, I don't think it is an issue.

Because as far as I understand, if you use answer codes like A1, A2, etc. LS takes it as strings (correct) and if it is 1,2, etc it takes it as integer/number and lets you compare it as numbers. Or am I mistaken.