Millisecond Forums

Resizing image on keypress / changing trial WHILE key is pressed

By Piko - 9/7/2014

Hello everyone!

I have to adapt an existing task ( ) which resizes images depending on whether the user moves the mouse up or down.
The goal is that it resizes the images by pressing the up or down arrow. I've been figuring out how the original task did it over the last 3 hours (including some adaptations for the images/texts of course :) )

Now the problem is that with the mouse movement it's possible to change trials on every input change.
See practicetrial_A/practicetrial_B and practicedecrease/practiceincrease:
/validresponse = (mousemove)
/branch = [if (trial.practicedecrease.responsey <= 0)
{values.mouse_y = trial.practicedecrease.responsey; values.endtime = script.elapsedtime; values.finalresponse = "PUSH"; trial.enddecrease_practice}]
/branch = [if (trial.practicedecrease.responsey <= values.mouse_y)
{values.mouse_y = trial.practicedecrease.responsey; trial.practicedecrease}]
/branch = [if (trial.practicedecrease.responsey > values.mouse_y)
{values.mouse_y = trial.practicedecrease.responsey; values.changedirection += 1; trial.practiceincrease}]

This can be found in the increase/decrease trials which let the image grow or shrink. It switches quickly from one trial to another, depending on mouse movement.

With the keypress it seems one has to press and release the key to make inquisit register it as an input and change the trial. But it's not very usable if one has to press 24+ times per second to make the image appear growing ;)
It's important to let the images grow/shrink animated and also to stop the growing/shrinking process when the user releases the corresponding key.

Do you, dear reader, have any suggestions on how to tackle that problem?



PS: Offtopic and not relevant, but when signing up and receiving the activation link, the text on the activation website told me that the user name should appear on the top left corner, even though it's in the top right corner. Not complaining, just letting someone know, as I couldn't find a subforum about the forum itself...
By Dave - 9/7/2014

The general idea you should consider is
(a) initiate the resizing upon registering a *key press*
(b) keep running the resizing trials in a loop until you register a *key release*

A key press is defined as a valid response by specifying its scan code:
/ validresponse = (57)
would register the spacebar being depressed.
The corresponding key release is defined as response by specifying the scan code with a prepended minus sign:
/ validresponse = (-57)
would register the spacebar being released.
By Piko - 9/8/2014

Hello Dave!

Ah, that's great to know that you can use keyReleases. I ended up leaving it with the mousemovement after all, but for future projects this might come in handy. Thank you so much for your solution!

Unrelated to the question: Is there any way we can use a more sophisticated programming language? Coming from Javascript/Java I have a really hard time writing 8 different trials where the only difference is a reference to a variable further up. I know that it's a scripting language and not a programming language, but I can't be the only one that would like to work more efficiently with inquisit...

Anyway, thanks again!

Take care

By Dave - 9/8/2014

There should be no need to set up 8 different <trial>s if they are all structurally identical. Instead you can make use of Inquisit's advanced features (conditional logic via event attributes etc.). If you need examples, tons of little ones are available on this forum. More elaborate examples can be found in the Task Library. If you look at something like the Tower of London, for instance, you'll find that Inquisit syntax is actually quite flexible / powerful (and its expressions are not that dissimilar from Java).

Hope this helps.
By Piko - 9/18/2014

Hi Dave!

Thanks again for your help. The semester started again and I've been terribly swamped and haven't gotten around to go over the script and make it doubleplusgood.

Unfortunately, a colleague tested the experiment and on her windows computer and even though she moved the mouse all the way to the bottom, the event wasn't triggered. I know it's a long shot, but do have any idea what the cause could be? We slightly adapted the code so that it's not about landscape or portrait mode anymore, but instead we added blue and violet borders that indicate if one has to move the mouse up or down. I haven't had the problem on Windows or OSX, but could reproduce it when accessing my windows PC via teamviewer. I assume it was because I wasn't in fullscreen mode though, so I'm not entirely sure that's the same problem.

The code is online here:

If you have any idea or suggestions, we'd appreciate it very much! It's really impressive how much you help the folks here in the forum, by the way
By Dave - 9/18/2014

I cannot reproduce this on my Windows box either, so I'm guessing there's something special about your colleague's particular machine. Offhand, I have no idea what that may be. To debug this, I would recommend (1) enabling data recording for any and all elements in the script (set /recorddata = true), (2) running the script on the affected machine and (3) examining the resulting data file. You may also want to temporarily add further variables to the data elements /columns. Particularly values.mouse_y should be of interest.

Also note that you can examine the state of all properties etc. at any time while the script is executing by pressing CTRL+D.

Let us know what you find.
By Piko - 10/2/2014

Hello Dave

I finally received the raw data from their trial. I logged the mouse_y position and *oh my god* there are negative values. So the mouse, on the topmost position, has a y value of -32 and on the lowest position a value of 991. This is exactly 32 less than the screen size they gave me (1024), minus the one pixel that's always missing. (my recordings also show 1079 instead of 1080 pixels, so I assume that's normal)

To me it seems like somehow the point of origin for the mouse position moved down 32 pixels but this does not make sense at all. Hopefully you or someone else has an idea..

By Dave - 10/2/2014

> I logged the mouse_y position and *oh my god* there are negative values.
Interesting (explains why it's not working as expected, of course). First guess would be a dodgy display driver, graphics card driver or other type of software running in the background on that system that messes with the display system (think: screen-sharing software, video-conferencing software, some application that spreads the desktop across multiple monitors, etc.). Can you figure out if any such thing might be the case? Also, (1) what's the OS / version on that machine?

> ... minus the one pixel that's always missing. (my recordings also show 1079 instead of 1080 pixels, so I assume that's normal)
Yup. Pixel indexing starts at zero. So, with 1080 pixels, you have 0 - 1079 (= 1080 pixels if you were to count them top to bottom).
By Piko - 10/2/2014

OS etc:
Windows 7 Professional on a Intel® Core i7-2640 CPU (1.80 GHz). Monitor: Lenovo LEN L171p Standard PnP-Monitor with Microsoft driver, Version 6.1.7600.16385. 17 inches, 1280 x 1024.That's unfortunately all I know so far, but I'll inquire about running programs. Good idea about the screen sharing program or similar!
By Piko - 10/2/2014

Ha, found it. They were using 2 screens. When the experiment runs on just one screen it works flawlessly. Do you think I should report that somewhere or is that such a small edge case that it's not worth mentioning?

Thanks for everything!

By Dave - 10/2/2014

I can file a report and see if we can reproduce and do anything about it. I'm a bit surprised, though, that a dual-screen setup would mess with y-coordinates, since most dual-monitor setups would extend the desktop *horizontally* not vertically (and perhaps throw off x-coordinates that way). My gut feeling is there's still some additional factor of that particular setup that's missing. Do you happen to know if they use Windows' built-in dual-monitor support or some 3rd party application in addition?