x

Hovedkapitler

  1. LimeSurvey Cloud vs LimeSurvey CE
  2. LimeSurvey Cloud - Hurtig startguide
  3. LimeSurvey CE - Installation
  4. Sådan designes en god undersøgelse (guide)
  5. Kom godt i gang
  6. LimeSurvey konfiguration
  7. Introduktion - Undersøgelser
  8. Se undersøgelsesindstillinger
  9. Se undersøgelsesmenuen
  10. Se undersøgelsens struktur
  11. Introduktion - Spørgsmål
  12. Introduktion - Spørgegrupper
  13. Introduktion - Undersøgelser - Ledelse
  14. Indstillinger for undersøgelsesværktøjslinje
  15. Flersproget undersøgelse
  16. Hurtig startguide - ExpressionScript
  17. Avancerede egenskaber
  18. Generelle FAQ
  19. Fejlfinding
  20. Løsninger
  21. Licens
  22. Versionsændringslog
  23. Plugins - Avanceret
 Actions

Check survey logic - Advanced/da: Difference between revisions

From LimeSurvey Manual

Maren.fritz (talk | contribs)
Created page with "== Farver i ExpressScript-syntaks == Betingelser og ligninger er syntaksfremhævede for lettere at finde ud af, hvad du ser på: # Grøn / Lyseblå: En variabel, der refererer..."
Maren.fritz (talk | contribs)
Created page with "Selvom LimeSurvey fuldt ud understøtter brugen af komma som radix (decimal) separator ved kørsel, skal du stadig bruge en decimal som radix separator på designtidspunktet (..."
 
(27 intermediate revisions by the same user not shown)
Line 83: Line 83:




==Undefined Variables==
==Udefinerede variable==




If undefined variables are used, the respective variable name will be color-coded in red and surrounded by a red line. If you hover your mouse over the variable name, it will say "undefined variable":
Hvis der anvendes udefinerede variabler, vil det respektive variabelnavn være farvekodet i rødt og omgivet af en rød linje. Hvis du holder musen over variabelnavnet, vil der stå "udefineret variabel":




Line 92: Line 92:




{{Alert|title=Attention|text=Please note that LimeSurvey does not allow survey administrators to create questions that use the same question code. However, it could happen to have similar question codes within a survey if you import a question group or a question that uses the same question code as one of your already-defined questions. The question can still be imported because the question ids are different. However, if you wish to export the survey results to further explore the [[Exporting_results|survey results]] (R or SPSS), be careful because the question code is seen as a variable!}}
{{Alert|title=Opmærksomhed|text=Bemærk venligst, at LimeSurvey ikke tillader undersøgelsesadministratorer at oprette spørgsmål, der bruger den samme spørgsmålskode. Det kan dog ske at have lignende spørgsmålskoder i en undersøgelse, hvis du importerer en spørgsmålsgruppe eller et spørgsmål, der bruger den samme spørgsmålskode som et af dine allerede definerede spørgsmål. Spørgsmålet kan stadig importeres, fordi spørgsmåls-id'erne er forskellige. Men hvis du ønsker at eksportere undersøgelsesresultaterne for yderligere at udforske [[Exporting_results|undersøgelsesresultaterne]] (R eller SPSS), skal du være forsigtig, da spørgsmålskoden ses som en variabel!}}




<center>[[File:same_code_name_not_recommended.png]]</center>}}
<center>[[File:same_code_name_not_recommended.png]]</center> }}


==Bad syntax==
==Dårlig syntaks==




Most of the expression-related mistakes are related to bad syntax. This is related to the fact that survey administrators usually miss to add a curly bracket, to properly make use of parentheses, or they use expressions wrongly:
De fleste af de udtryksrelaterede fejl er relateret til dårlig syntaks. Dette er relateret til det faktum, at undersøgelsesadministratorer normalt savner at tilføje en krøllet parentes, for at bruge parenteser korrekt, eller de bruger udtryk forkert:




Line 108: Line 108:




Here are many good examples on the usage of [[ExpressionScript How-tos#Syntax_Highlighting|syntax highlighting]].
Her er mange gode eksempler på brugen af [[ExpressionScript How-tos#Syntax_Highlighting|syntax highlighting]].




===Bad custom JavaScript===
===Dårlig tilpasset JavaScript===




The JavaScript errors will also be highlighted in the survey logic check:
JavaScript-fejlene vil også blive fremhævet i undersøgelsens logikcheck:




<center>[[File:javascript_error.jpg]]</center>
<center>[[File:javascript_error.jpg]]</center>


=Speeding editing and validation=
=Hastighedsredigering og validering=




All of the syntax-highlighted text has tooltips embedded, which are clickable:
Al den syntaks-fremhævede tekst har værktøjstip indlejret, som er klikbare:
#Tooltips
#Tooltips
#*Functions - hovering the mouse lets you see the purpose and syntax definition of the function;
#*Functions - ved at holde musen svævende kan du se formålet og syntaksdefinitionen af funktionen;
#*Variable Names - hovering the mouse lets you see the position (group, question sequence), question text, and allowable answers for the question.
#*Variable Names - svæver du med musen, kan du se positionen (gruppe, spørgsmålssekvens), spørgsmålstekst og tilladte svar på spørgsmålet.
#Actions
#Actions
#*Variable Names - clicking on the variable name opens a new window that allows you to edit the question. This makes it easy to navigate and verify logic - simply keep clicking on variable names of relevance or validation criteria for the question to see where they come from and how they are used.
#*Variable Names - ved at klikke på variabelnavnet åbnes et nyt vindue, der giver dig mulighed for for at redigere spørgsmålet. Dette gør det nemt at navigere og verificere logik - bare fortsæt med at klikke på variabelnavne af relevans eller valideringskriterier for spørgsmålet for at se, hvor de kommer fra, og hvordan de bruges.




=Examples=
=Eksempler=




The following examples are taken from the [[ExpressionScript sample surveys|ExpressionScript sample surveys]]. You can find screenshots of running surveys, explanations, and downloads on that page.
De følgende eksempler er taget fra [[ExpressionScript-eksempelundersøgelserne|ExpressionScript-eksempelundersøgelserne]]. Du kan finde skærmbilleder af kørende undersøgelser, forklaringer og downloads på den side.




==Body Mass Index==
==Kropsmasseindeks==




Here are [[ExpressionScript sample surveys#Screenshots|screenshots]] of this example.
Her er [[ExpressionScript-eksempelundersøgelser#Skærmbilleder|skærmbilleder]] af dette eksempel.


This is the question-reorder view of the Body Mass Index calculation. You can see the relevance equations for weight, height, and BMI under the ''Question'' column:
Dette er spørgsmålet-genbestillingsvisningen af Body Mass Index-beregningen. Du kan se relevansligningerne for vægt, højde og BMI under kolonnen ''Spørgsmål'':




Line 147: Line 147:




For a better survey overview, check the survey logic page:
For en bedre undersøgelsesoversigt, tjek undersøgelseslogiksiden:




Line 153: Line 153:




This survey example is also a good example of nested if() statements to generate the "weightstatus".
Dette undersøgelseseksempel er også et godt eksempel på indlejrede if()-sætninger til at generere "vægtstatus".




<center>[[File:BMI_logic2.jpg]]</center>
<center>[[File:BMI_logic2.jpg]]</center>


==Cascading logic==
==Cascading logik==




Here are [[ExpressionScript sample surveys#Cascading Array Filters|screenshots]] of this example.
Her er [[ExpressionScript-eksempelundersøgelser#Cascading Array Filters|skærmbilleder]] af dette eksempel.


It shows the subquestion validation logic that is automatically generated when you use [[QS:Array_filter|array_filter]] and [[QS:Array_filter_exclude|array_filter_exclude]]. This example also shows how you can substitute the tailored "Other" value (the answer for Q02_other is Q01_other).
Den viser valideringslogikken for underspørgsmål, der genereres automatisk, når du bruger [[QS:Array_filter|array_filter]] og [[QS:Array_filter_exclude|array_filter_exclude]]. Dette eksempel viser også, hvordan du kan erstatte den skræddersyede "Andet"-værdi (svaret for Q02_other er Q01_other).




Line 169: Line 169:




Q05 in this example shows simultaneous use of array_filter and array_filter_exclude on Q01 and Q02, respectively. This example demonstrates cascading array_filter capabilities. Note that one of the main reasons for showing the question and subquestion level '''validation''' criteria is to help ensure you have not made any typos in specifying the array_filter or array_filter_exclude variable names (or in case you use different variable names for your list of filtered subquestions). If you have such typos, all the invalid variable names will appear in red indicating that they are undefined, letting you quickly fix the problem.
Q05 i dette eksempel viser samtidig brug af array_filter og array_filter_exclude på henholdsvis Q01 og Q02. Dette eksempel viser cascading array_filter-egenskaber. Bemærk, at en af hovedårsagerne til at vise spørgsmåls- og underspørgsmålsniveauet '''validering'''-kriterier er at hjælpe med at sikre, at du ikke har lavet nogen tastefejl ved at specificere array_filter eller array_filter_exclude variabelnavne (eller hvis du bruger forskellige variabelnavne til din liste over filtrerede underspørgsmål). Hvis du har sådanne tastefejl, vil alle de ugyldige variabelnavne blive vist i rødt, hvilket indikerer, at de er udefinerede, så du hurtigt kan løse problemet.




Line 175: Line 175:




==Dynamic relevance==
==Dynamisk relevans==




This example demonstrates dynamic cascading relevance logic to control display of question visibility. You can download this example [[ExpressionScript sample surveys#Download|here]].
Dette eksempel demonstrerer dynamisk kaskaderelevanslogik til at kontrollere visningen af spørgsmålets synlighed. Du kan downloade dette eksempel [[ExpressionScript sample surveys#Download|her]].


Also note that questions are displayed only if certain validation criteria are met. For example, if a person states that she has 2 kids, certain questions have to be filled in by the respondent (kid1 and kid2).
Bemærk også, at spørgsmål kun vises, hvis visse valideringskriterier er opfyldt. For eksempel, hvis en person angiver, at hun har 2 børn, skal visse spørgsmål udfyldes af respondenten (kid1 og kid2).




<center>[[File:dynamic_relevance_logic1.jpg]]</center>
<center>[[File:dynamic_relevance_logic1.jpg]]</center>


==Group-level relevance==
==Relevans på gruppeniveau==




This example shows how group-level relevance appears in the logic check. Here are [[ExpressionScript sample surveys#Sample Census|screenshots]] of the example described below.
Dette eksempel viser, hvordan relevans på gruppeniveau vises i logikkontrollen. Her er [[ExpressionScript-eksempelundersøgelser#Sample Census|skærmbilleder]] af eksemplet beskrevet nedenfor.


As you can see, the group-level relevance equation (cohabs > 1 && p1_rel != "") appear in the grey Person 2 row for G-2.
Som du kan se, vises relevansligningen på gruppeniveau (cohabs > 1 && p1_rel != "") i den grå person 2-række for G-2.


You may also notice that all of the questions are mandatory. However, if the group is irrelevant, so are all its questions. As a result, those questions are only truly mandatory if the group is relevant.
Du kan også bemærke, at alle spørgsmålene er obligatoriske. Men hvis gruppen er irrelevant, så er alle dens spørgsmål også. Som følge heraf er disse spørgsmål kun virkelig obligatoriske, hvis gruppen er relevant.


You may also note that certain questions are displayed only if the answer to the previous question is not empty. You may see below that if p2_sex is not filled in, p2_name is not going to be displayed, even though it is a mandatory questions. The mandatory question p2_age is also not going to be displayed if p2_name is not filled in. These questions can be considered "conditionally mandatory".  
Du kan også bemærke, at visse spørgsmål kun vises, hvis svaret på det foregående spørgsmål ikke er tomt. Du kan se nedenfor, at hvis p2_sex ikke er udfyldt, vil p2_name ikke blive vist, selvom det er et obligatorisk spørgsmål. Det obligatoriske spørgsmål p2_age vil heller ikke blive vist, hvis p2_name ikke er udfyldt. Disse spørgsmål kan betragtes som "betinget obligatoriske".  


Additionally, note that the '''tip''' messages are also automatically created for you. They are organized by value range (min/max), sum value range (min/max/equals), number of answers (min/max), etc (it depends on the used question type and active attributes). Sometimes you want to validate an answer range but don't want to display what might appear to be silly validation tips to the user. In such cases, you can use the [[QS:Hide_tip|hide_tip]] question option (as in this case, to avoid telling the user that the age must be between 0 and 115 unless they try to enter a bad value - see p2_age).
Bemærk desuden, at '''tip'''-meddelelserne også oprettes automatisk til dig. De er organiseret efter værdiområde (min/maks), sumværdiområde (min/maks/lig med), antal svar (min/maks) osv. (det afhænger af den anvendte spørgsmålstype og aktive attributter). Nogle gange ønsker du at validere et svarområde, men ønsker ikke at vise, hvad der kan se ud til at være dumme valideringstip til brugeren. I sådanne tilfælde kan du bruge spørgsmålsmuligheden [[QS:Hide_tip|hide_tip]] (som i dette tilfælde for at undgå at fortælle brugeren, at alderen skal være mellem 0 og 115, medmindre de forsøger at indtaste en dårlig værdi - se p2_age ).




<center>[[File:person2_logic.jpg]]</center>
<center>[[File:person2_logic.jpg]]</center>


==Comma as radix (decimal) separator==
==Komma som radix (decimal) separator==




Although LimeSurvey fully supports the use of comma as radix (decimal) separator at run-time, you must still use a decimal as the radix separator at the design-time (e.g., when specifying min/max values in advanced question attributes). The working example can be [[ExpressionScript sample surveys#Using Comma as Radix Separator (Decimal Point)|found here]].
Selvom LimeSurvey fuldt ud understøtter brugen af komma som radix (decimal) separator ved kørsel, skal du stadig bruge en decimal som radix separator på designtidspunktet (f.eks. når du angiver min/max værdier i avancerede spørgsmål attributter). Arbejdseksemplet kan være [[ExpressionScript-eksempelundersøgelser#Using Comma as Radix Separator (decimalpunkt)|findes her]].


Also, remember that the '''validation''' logic is created for you automatically from the enabled question attributes. The equations may look overwhelming, but you don't need to worry about them.
Husk også, at '''valideringslogikken''' oprettes automatisk for dig ud fra de aktiverede spørgsmålsattributter. Ligningerne kan se overvældende ud, men du behøver ikke bekymre dig om dem.




<center>[[File:radix_logic1.jpg]]</center>
<center>[[File:radix_logic1.jpg]]</center>

Latest revision as of 11:52, 2 January 2024


Generelt

En vigtig mulighed, der hjælper dig med at oprette og nemt vedligeholde komplekse undersøgelser, er Check Survey Logic.

Under hele udviklingen og afprøvningen af undersøgelsen, og før den aktiveres, er det meget vigtigt at validere undersøgelseslogikken. Dette gælder især, når du bruger komplekse relevans-, skræddersy- og valideringsligninger - du skal være sikker på, at intet går i stykker, når du kører undersøgelsen.

Denne funktion lader dig hurtigt validere nøjagtigheden af din undersøgelse, gruppe(r) og spørgsmål. Den kan tilgås fra menuindstillingerne i den øverste bjælke, der er placeret under de undersøgelsesrelaterede indstillinger. Den er tilgængelig via menuen Værktøjer:


Fil:show_logic_file.jpg


Som du kan se ovenfor, kan du køre denne mulighed fire gange for hvert sprog, der bruges i en undersøgelse.

Beskrivelse

Valgmuligheden Kontroller undersøgelseslogik viser alt, hvad du har angivet for hvert spørgsmål og gruppe (f.eks. navn, tekst, hjælp, betingelser/relevans, valideringsregler, standardindstillinger, underspørgsmål, svar) i et praktisk tabelformat. Det fremhæver fejlene og lader dig klikke på spørgsmålet og gruppe-id'erne (eller variabler, der bruges i ligninger) for at åbne nye browserfaner for at redigere disse spørgsmål eller grupper. Dette gør det nemt hurtigt at redigere eventuelle fejl og opdatere logikkontrolsiden for at bekræfte undersøgelsens nøjagtighed, før den aktiveres.

Displayet er også designet til at kunne læses af forskere og studiesponsorer, så de kan validere nøjagtigheden af undersøgelsens design og logik. Kontrol af undersøgelseslogikken opdaterer cachen for alle udtryk, der bruges i en aktiv undersøgelse.

Det inkluderer følgende kolonner:

  • # - viser antallet af gruppe- og spørgsmålssekvenser, startende fra 0.
  • Navn [ ID] - viser spørgsmålskoden for gruppen/spørgsmålet/underspørgsmålet. Disse koder kan bruges som variable i udtryk. ID er spørgsmåls-id (QID) eller gruppe-id (GID). Dette felt viser også spørgsmålstype (f.eks. Multiple choice [M])).


For at finde ud af mere om, hvilke variabler der kan bruges i udtryk, læs følgende wiki underafsnit.


  • Relevans [ Validering] (Standard) - viser følgende:
    • Relevans - den syntaks-fremhævede relevansligning for spørgsmålet eller gruppen. Hvis det altid er sandt (skal vises i ethvert scenarie), vil værdien være 1.
    • Validation - ExpressionScript genererer automatisk valideringen ligning baseret på de valgte spørgsmålsattributter (f.eks. min/maks. antal svar, min/maks/lig med sumværdier, min/maks individuelle værdier eller validering af regulære udtryk). Dette afsnit viser den genererede valideringsligning, så du kan opdage, om der er fejl (såsom udefinerede variabler).
      • Validering på spørgsmålsniveau viser den ligning, der er nødvendig for at verificere de ovenfor beskrevne spørgsmålsattributter
  • **Validering på underspørgsmålsniveau viser den ligning, der er nødvendig for at implementere array_filter, array_filter_exclude og exclusive_option
    • Standard - hvis spørgsmålet har en standardværdi, vises det her, syntaks-fremhævet (da standarden kunne være et udtryk).
  • Tekst [ Hjælp] (Tip) - viser følgende:
    • Tekst - teksten til gruppen, spørgsmålet, underspørgsmålet eller svaret. Det er syntaks-fremhævet for at vise enhver indlejret skræddersy, således at du kan bekræfte, at du har erklæret alle de variabler, du planlægger at bruge i skræddersyet.
    • Hjælp - dette viser hjælpeteksten til spørgsmålet, også syntaks-fremhævet.
    • Tip - dette viser det internt genererede valideringstip, baseret på spørgsmålets attributter. Det samme tip bruges i alle undersøgelsesstile, plus i de udskrivbare undersøgelses- og dataindtastningsskærme.
    • Spørgsmålsattributter - dette viser en tabel med alle relevante spørgsmålsattributter for dette spørgsmål. Attributter, der kan være ligninger, er syntaks-fremhævede, så du kan validere deres nøjagtighed.

Rækker er farvekodet som følger:

  • Grupper - vises med en lysegrå baggrund
  • Spørgsmål - vises med en lysegrøn baggrund
  • ' Underspørgsmål' - vises med en lysegul baggrund
  • Svar - vises med en almindelig hvid baggrund

Svar har en ekstra egenskab i kolonnen Relevans:

  • Værdi - dette er den interne standardværdi, der bruges til beregninger. Hvis du bruger vurderinger, vil dette være vurderingsværdien. Ellers vil dette være det samme som svarets navn.


Template:Bemærk

Brug

Øverst på siden er der en opsummerende besked. Hvis alt er godt, vil der stå "Ingen syntaksfejl fundet i denne undersøgelse", eller "Denne gruppe" eller "Dette spørgsmål", "indeholder i sig selv ingen syntaksfejl". Hvis det modsatte er sandt, vil der stå "X spørgsmål har syntaksfejl, der skal rettes".

Hvert spørgsmål, der har syntaksfejl, får baggrunden for sin kolonne længst til venstre (dvs. #) farvekodet rød. Desuden vil en advarsel, der angiver antallet af minimumsfejl i et spørgsmål, blive vist under kolonnen Navn [ID]. Følgende fejl er almindelige:

  • Udefineret variabel - hvis du ikke har defineret alle dine variabler, eller har skrevet forkert array_filter (eller forskellige sæt svarmuligheder for array_filter), så vil nogle af dine valideringsspørgsmål vise fejl . Udefinerede variabler vises i rød tekst, indrammet med en rød linje.
  • Dårlig syntaks - når du begynder at bruge relevansligninger, kan du bruge for mange eller for få parenteser. Sådanne syntaksproblemer er fremhævet og indrammet med rødt. Hvis du holder musen over en sådan tekst med røde felter, vil et værktøjstip beskrive fejlen.

Farver i ExpressScript-syntaks

Betingelser og ligninger er syntaksfremhævede for lettere at finde ud af, hvad du ser på:

  1. Grøn / Lyseblå: En variabel, der refererer til et spørgsmål tidligere i undersøgelsen
  2. Blå : En funktion
  3. Grå: Et strengudtryk
  4. Brun: ET TOKEN-udtryk (deltagerdata)
  5. Sort: Operator

Ting at tjekke:

  1. Lilla: En variabel, der refererer til en spørgsmål senere i undersøgelsen. Normalt er dette en fejl og skal kontrolleres.
  2. Rød eller rød ramme: En ikke-eksisterende variabel eller reference til et tidligere spørgsmål eller en syntaksfejl - skal normalt kontrolleres.


Udefinerede variable

Hvis der anvendes udefinerede variabler, vil det respektive variabelnavn være farvekodet i rødt og omgivet af en rød linje. Hvis du holder musen over variabelnavnet, vil der stå "udefineret variabel":



  Opmærksomhed : Bemærk venligst, at LimeSurvey ikke tillader undersøgelsesadministratorer at oprette spørgsmål, der bruger den samme spørgsmålskode. Det kan dog ske at have lignende spørgsmålskoder i en undersøgelse, hvis du importerer en spørgsmålsgruppe eller et spørgsmål, der bruger den samme spørgsmålskode som et af dine allerede definerede spørgsmål. Spørgsmålet kan stadig importeres, fordi spørgsmåls-id'erne er forskellige. Men hvis du ønsker at eksportere undersøgelsesresultaterne for yderligere at udforske undersøgelsesresultaterne (R eller SPSS), skal du være forsigtig, da spørgsmålskoden ses som en variabel!



}}

Dårlig syntaks

De fleste af de udtryksrelaterede fejl er relateret til dårlig syntaks. Dette er relateret til det faktum, at undersøgelsesadministratorer normalt savner at tilføje en krøllet parentes, for at bruge parenteser korrekt, eller de bruger udtryk forkert:



Her er mange gode eksempler på brugen af syntax highlighting.


Dårlig tilpasset JavaScript

JavaScript-fejlene vil også blive fremhævet i undersøgelsens logikcheck:


Hastighedsredigering og validering

Al den syntaks-fremhævede tekst har værktøjstip indlejret, som er klikbare:

  1. Tooltips
    • Functions - ved at holde musen svævende kan du se formålet og syntaksdefinitionen af funktionen;
    • Variable Names - svæver du med musen, kan du se positionen (gruppe, spørgsmålssekvens), spørgsmålstekst og tilladte svar på spørgsmålet.
  2. Actions
    • Variable Names - ved at klikke på variabelnavnet åbnes et nyt vindue, der giver dig mulighed for for at redigere spørgsmålet. Dette gør det nemt at navigere og verificere logik - bare fortsæt med at klikke på variabelnavne af relevans eller valideringskriterier for spørgsmålet for at se, hvor de kommer fra, og hvordan de bruges.


Eksempler

De følgende eksempler er taget fra ExpressionScript-eksempelundersøgelserne. Du kan finde skærmbilleder af kørende undersøgelser, forklaringer og downloads på den side.


Kropsmasseindeks

Her er skærmbilleder af dette eksempel.

Dette er spørgsmålet-genbestillingsvisningen af Body Mass Index-beregningen. Du kan se relevansligningerne for vægt, højde og BMI under kolonnen Spørgsmål:



For en bedre undersøgelsesoversigt, tjek undersøgelseslogiksiden:



Dette undersøgelseseksempel er også et godt eksempel på indlejrede if()-sætninger til at generere "vægtstatus".


Cascading logik

Her er skærmbilleder af dette eksempel.

Den viser valideringslogikken for underspørgsmål, der genereres automatisk, når du bruger array_filter og array_filter_exclude. Dette eksempel viser også, hvordan du kan erstatte den skræddersyede "Andet"-værdi (svaret for Q02_other er Q01_other).



Q05 i dette eksempel viser samtidig brug af array_filter og array_filter_exclude på henholdsvis Q01 og Q02. Dette eksempel viser cascading array_filter-egenskaber. Bemærk, at en af hovedårsagerne til at vise spørgsmåls- og underspørgsmålsniveauet validering-kriterier er at hjælpe med at sikre, at du ikke har lavet nogen tastefejl ved at specificere array_filter eller array_filter_exclude variabelnavne (eller hvis du bruger forskellige variabelnavne til din liste over filtrerede underspørgsmål). Hvis du har sådanne tastefejl, vil alle de ugyldige variabelnavne blive vist i rødt, hvilket indikerer, at de er udefinerede, så du hurtigt kan løse problemet.



Dynamisk relevans

Dette eksempel demonstrerer dynamisk kaskaderelevanslogik til at kontrollere visningen af spørgsmålets synlighed. Du kan downloade dette eksempel her.

Bemærk også, at spørgsmål kun vises, hvis visse valideringskriterier er opfyldt. For eksempel, hvis en person angiver, at hun har 2 børn, skal visse spørgsmål udfyldes af respondenten (kid1 og kid2).


Relevans på gruppeniveau

Dette eksempel viser, hvordan relevans på gruppeniveau vises i logikkontrollen. Her er skærmbilleder af eksemplet beskrevet nedenfor.

Som du kan se, vises relevansligningen på gruppeniveau (cohabs > 1 && p1_rel != "") i den grå person 2-række for G-2.

Du kan også bemærke, at alle spørgsmålene er obligatoriske. Men hvis gruppen er irrelevant, så er alle dens spørgsmål også. Som følge heraf er disse spørgsmål kun virkelig obligatoriske, hvis gruppen er relevant.

Du kan også bemærke, at visse spørgsmål kun vises, hvis svaret på det foregående spørgsmål ikke er tomt. Du kan se nedenfor, at hvis p2_sex ikke er udfyldt, vil p2_name ikke blive vist, selvom det er et obligatorisk spørgsmål. Det obligatoriske spørgsmål p2_age vil heller ikke blive vist, hvis p2_name ikke er udfyldt. Disse spørgsmål kan betragtes som "betinget obligatoriske".

Bemærk desuden, at tip-meddelelserne også oprettes automatisk til dig. De er organiseret efter værdiområde (min/maks), sumværdiområde (min/maks/lig med), antal svar (min/maks) osv. (det afhænger af den anvendte spørgsmålstype og aktive attributter). Nogle gange ønsker du at validere et svarområde, men ønsker ikke at vise, hvad der kan se ud til at være dumme valideringstip til brugeren. I sådanne tilfælde kan du bruge spørgsmålsmuligheden hide_tip (som i dette tilfælde for at undgå at fortælle brugeren, at alderen skal være mellem 0 og 115, medmindre de forsøger at indtaste en dårlig værdi - se p2_age ).


Komma som radix (decimal) separator

Selvom LimeSurvey fuldt ud understøtter brugen af komma som radix (decimal) separator ved kørsel, skal du stadig bruge en decimal som radix separator på designtidspunktet (f.eks. når du angiver min/max værdier i avancerede spørgsmål attributter). Arbejdseksemplet kan være findes her.

Husk også, at valideringslogikken oprettes automatisk for dig ud fra de aktiverede spørgsmålsattributter. Ligningerne kan se overvældende ud, men du behøver ikke bekymre dig om dem.