Your LimeSurvey version: LimeSurvey Community Edition Version 5.3.27+220725
Own server or LimeSurvey hosting: Own (local instance on a laptop)
Survey theme/template: Fruity
==================

Hello,

I'm not sure what's going on so here's my problem with validation:

The question type is Multiple choice with comments with one option (SQ001)

Validation equation:
(is_empty(G00Q01_SQ001comment) OR regexMatch("/^(\<[0-9]+)(\.[0-9]+)?$/", G00Q01_SQ001comment))

Validation tip:
{if(!is_empty(G00Q01_SQ001comment) OR !regexMatch("/^(\<[0-9]+)(\.[0-9]+)?$/", G00Q01_SQ001comment), "Upper limit<br>")}

Now, the validation seems to work as intended. For instance comment <2 looks ok, but <2safsaf turns the field red with error message "Upper limit".

However, when trying to submit, a dialog with "One or more questions have not been answered in a valid manner. You cannot proceed until these answers are valid." pops up even though the UI is "all green" with inputted <2

What might be the cause? Thanks!

Can you attach a small survey export (.lss file) containing only that question?

The first thing I see is the wrong negation of logical terms
A OR C  -> !(A OR C)  = !A AND !C

(is_empty(G00Q01_SQ001comment) OR regexMatch("/^(\<[0-9]+)(\.[0-9]+)?$/", G00Q01_SQ001comment))
You want to negate this.

{if(!is_empty(G00Q01_SQ001comment) AND !regexMatch("/^(\<[0-9]+)(\.[0-9]+)?$/", G00Q01_SQ001comment), "Upper limit<br>")}
Obviously both have to be fulfilled (not empty AND not matching the regex)
With the OR this logical term is true when the comment is not empty and shows the error message.
 

Thanks for the answers!I tried to change the validation tip as suggested. The tip in the UI indeed vanishes now when the input is correct so I got the point of that. However, the original problem remains: I still cannot submit the answer even though the UI is all green. Here are some screenshots to illustrate (original validation so the tip is visible when green): 

Input ok


Input ok, click submit


Wrong input


I'm a frontend developer so I may be wrong with this but could this be some problem with the backend and the input string starting with a "<"? I mean the UI looks okay but something happens the moment one clicks "submit", which makes little sense to me...

Here's the export (also original validators):

 

Never send lsq nor lsg exports, only lss.
Reason: lsq and lsg exports are language sensitive. You only can import them into a survey with the same base language.
Meaning: To help you, we have create a survey guessing the base language of your export.
Furthermore the systemwide settings aren't there.

So, please, ease our life.
Copy the survey, remove everything not relevant and send this as lss export.

Joffm
 

Noted, my bad...

There is an issue with the "<".

But if I understand your question correctly:
You want the participants to enter a number and the upper limit is below this number.
Let's say the participant enters "<22.345"
upper limit < 22.345
So the upper limit can be 17 or 5.123 or 22.1.
And of course, an answer like that is difficult to use later in equations where you want to calculate something.
In my opinion the participant enters the real upper limit. No need to prepend a "<".

Or do I misunderstand?

In the example you show you might have used a question of type "short text" or "numerical input".
Here you can use a prefix to show the "<"

Joffm

Sorry, I'm probably a bit unclear. I guess it would be easier to provide a dummy example of the real use case I'm trying to do. Consider a medical professional inputting measured values extracted from a blood test (in arbitrary amount per volume units). There are a bunch of known markers but not all of them are needed in all cases -> Multiple choice with comments seems the most convenient field type for this. Now, some markers have exact values (e.g. 2.3333) but some do not (cannot be precisely measured or exact value is irrelevant) so they should input an upper limit (e.g. <2 implying a measured value in between 0 and 2). Something like this:

 

This seems to be an acceptable input until I introduce that custom validator after which the submission is not working (although the UI would indicate that the input is accepted). So the problem may somehow be with the regexMatch function? I have tested all my regex within an online sandbox but apparently those can differ as well...

So I guess the real question is: can I setup Multiple choice with comments in a way it accepts only numeric values and numeric values starting with a "<"?

We really want to setup a proper validators instead of leaving them as is as users (MDs or not) oftentimes input incorrect values which mess up the analytics done afterwards using some different software.

I have tried to understand the problem further with no luck. According to the manual:

Expression Manager provides access to mathematical, string, and user-defined functions, as shown below.  It has PHP and JavaScript equivalents for these functions so that they work identically on server-side (PHP) and client-side (JavaScript).

Now, I'm assuming that the frontend part works as expected since the UI does not show a validation tip when the input is in correct format. Furthermore, I have gathered that the PHP uses preg_match() method, which should handle strings starting with a "<" correctly. I'm left with two guesses at this point. Either the input is somehow converted to something else than a string at some point (probably not?) or the problem is in somewhere else completely. In any case, I was thinking of circumventing the problem using some custom frontend-only validation with JavaScript that hopefully works until this might get fixed.

In any case, I was thinking of circumventing the problem using some custom frontend-only validation with JavaScript that hopefully works until this might get fixed.

If you feel this is something that needs fixing, then you need to make a bug report. Otherwise it will probably never get fixed. Your case sounds pretty unique and most users might never run into this anyway, so it might not be noticed, in case it is a bug/issue rather than a "feature".

So if you think that this is an issue: bugs.limesurvey.org/

Okay, thanks! I just found out that this probably has nothing to do with the validators but something else. I'll submit a report.