Fred wrote: At Limesurvey 2.1 there will also be a thousand separator available. So when you set the decimal separator to "." (US number format), the thousands separator will automatically be set to "," and vice versa.

This is implemented for the numeric question types to make large numbers easier to read when inputting them.
I'm not sure if this might cause any conflicts e. g. when using EM because only the number display is adjusted while the actual storing of the value should not have changed, but if someone notices any problems, please file a bug report and post the link to the report here.

Mazi wrote
Yes, Denis told me a little about that. Hopefully it will work on Inputs so we don't have to do all this custom JS masking. And it can work equivalently in Expressions just for display but without saving to the database. It would be nice if we could get prefix/suffix into Equations somehow as well. I use them for $ and % signs.

This business of having to create two questions for everything is not very user-friendly for typical survey creator

What is the roadmap for 2.1 anyway? I keep hearing about it, but there's not much on the site. Maybe this could use an update
docs.limesurvey.org/LimeSurvey+roadmap&highlight=2.1

Fred wrote:
I totally agree that the two question solution is not the best case, but most surveys are not that complex and thus you can use the assessment feature for most of the simple stuff.

Nevertheless, if you have a good idea on how we can easily mass-add equations to Limesurvey questions, please write a proposal we can discuss.

As for the roadmap: A first Limesurvey 2.1 alpha release is planned for end of January. As so often, my guess would be that it will be February for a first version and maybe April/May for the stable release (just guessing).

Yes, not the best.. BUT it does work! (Thank you Tom)

Mazi, if you click on my karma button so that it will finally go above zero, then I will think about this equations issue!

Mazi wrote: Hello Marcel,

I look at 2.1 code, and don't see this system, and EM function are var numRegex = new RegExp('[^-' + LEMradix + '0-9]','g'); : no thousand seperator here .

Are you sure it's in 2.1 actually ?

Denis

Hi Denis,

this should be in 2.1 already. Please contact Sam about the details, he has coded that.

A follow up to one of my earlier comments. I said a couple of weeks ago...

Actually I discovered that LS actually DOES create a column in the survey responses table for Text Display (Boilerplate) questions. This may have been introduced between 1.91 and 1.92 according to Denis? It's only varchar(1) so fortunately it doesn't take up too much room. But if you have a large survey, you may want to factor this into your estimates:
docs.limesurvey.org/General+FAQ#regarding_survey_size

It does seem a little silly to have all these empty columns in the responses. Usually sparseness is a quality you want to avoid in DB. But if Thomas White did this, I'm sure there was an excellent reason!

As far as I remember, 1.91 did also create a varchar(1) for each boilerplate question even though it could never contain anything. I left it in for backwards compatability.

However, I'd vote to remove those columns in version 2.1

/Tom

Fortunately, for the big survey I was working on, even with the extra overhead of many text display questions for equation formatting, everything worked out great so far.

I built everything in Excel, coding all the expressions using Excel formulas, concatenate, etc. There are probably 1000 expressions including equations and relevance. This took a few weeks. Then I imported it using the Tab-delimited Text import utility. The import and table build took about 2 seconds and worked perfectly. And I can run through the survey without crashing, too

There is absolutely no way this could have been done without Expression Manager and the Text importer!

1744 rows in text import file
1558 columns in Survey_NNN table
Question groups: 35
Questions: 1494
Answers: 102
Subquestions: 60
Question attributes: 4145

The MySQL table schema has this data, but I'm not sure how to interpret. The data length sounds too little and the max length sounds too big?

AVG_ROW_LENGTH 2468
DATA_LENGTH 2468
MAX_DATA_LENGTH 281,474,976,710,655
INDEX_LENGTH 12288