Millisecond Forums

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?

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!

piko

DELETE ME

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!

DELETE ME

> 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).

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..

Thanks!

DELETE ME

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.

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: http://pastebin.com/1uaUyH8Q

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

DELETE ME

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.

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

Piko

DELETE ME

The general idea you should consider is
(a) initiate the resizing upon registering a *key press*
then
(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.