Stop Force Response from re-triggering Javascript Qualtrics.SurveyEngine.addOnload() | XM Community
Solved

Stop Force Response from re-triggering Javascript Qualtrics.SurveyEngine.addOnload()

  • 9 June 2023
  • 6 replies
  • 159 views

Userlevel 3
Badge +10
  • Level 3 ●●●
  • 35 replies

I have a Qualtrics question that involves participants drawing on an HTML5 Canvas element, and then saves their drawing (using dataToUrl). Below, on the same page, is another question that has forced response enabled. I need it to be on the same page as the Canvas question.

The issue is that when Force Response is triggered, the page essentially refreshes - any code in Qualtrics.SurveyEngine.addOnload() is triggered again, meaning that all the canvas initialization scripts are triggered again, erasing whatever has been drawn.

Is there a way to stop Force Response from re-running whatever is in Qualtrics.SurveyEngine.addOnload?

icon

Best answer by nroot 14 June 2023, 15:37

View original

6 replies

Userlevel 7
Badge +32

there are two methods for canvas. Save and restore.

Refer this link and see if anything helps you.

https://www.tutorialspoint.com/html5/canvas_states.htm

Userlevel 7
Badge +27

@nroot - You can set an embedded data field in addOnPageSubmit() then include it in your addOnload() function logic.

Userlevel 3
Badge +10

The issue isn’t manipulations within the canvas, the issue is that the entire page is getting reloaded when Force Response is triggered, so from the perspective of the code, there is nothing to restore.

 

My current specific use case is for Canvas, but I made a much less complicated minimal working example to show specifically the problem I am facing (zipped QSF attached).

 

In the MWE there are two questions, a slider and a multiple choice question. I use javascript to choose a random integer 1-100, and on page ready set the value of the slider to the random number. Move the slider around as if you are answering the question. Now “forget” to answer the multiple choice question and press submit. The “Force Response” trigger reloads the page, triggering Javascript to move the slider to a new random position. I want it to instead not run the code again (or somehow only run the code if it “knows” that this is the first time the page has been loaded).

Userlevel 3
Badge +10

@nroot - You can set an embedded data field in addOnPageSubmit() then include it in your addOnload() function logic.

Ah yes, this works, but now I’m having trouble figuring out where in the logic I should reset the embedded variable if I’m inside a loop and merge.

So, “submitted” is initialized to zero, I only run my onload code if submitted is 0. On page submit I set submitted to 1, now if force response triggers it won’t run the onload code again (which is correct). But now I answer the question, submit again, and it successfully goes to the next loop in the loop and merge. How do I set submitted back to 0 only when this happens?

Silly I know, but I wish there were an addOnSuccessfulPageSubmit() that let you change an embedded variable only if Forced Responses weren’t triggered and you successfully go to the next page.

Userlevel 7
Badge +27

Since it is in a loop, you can check if the forced response question is answered in the addOnPageSubmit() function. If it isn’t answered, set the embedded field to 1, otherwise set it to zero.

Userlevel 3
Badge +10

 

Since it is in a loop, you can check if the forced response question is answered in the addOnPageSubmit() function. If it isn’t answered, set the embedded field to 1, otherwise set it to zero.

 

This works for the simple QSF example above. Unfortunately, the general strategy of running the onLoad only in certain conditions does not fix the Canvas issue - the Canvas is reset when Force Response is triggered. I’m not sure there’s a way to work around the underlying problem that the page is refreshed when Force Response is triggered.

Ultimately, I ended up removing Force Response entirely, and instead hiding the next button until the participant answered all questions. I’m assuming that this is the best solution for now, unless Qualtrics actually changed how Force Response is implemented.

Leave a Reply