|
|
|
Forum Newbie
Group: Forum Members
Last Login: 10/13/2008 7:30:54 AM
Posts: 4,
Visits: 24
|
|
I ran across a rather peculiar behavior of the c.GetAttrib method when trying to read the RESP, CRESP and ACC properties of a textdisplay object. I've created a simple experiment (see attachment) that shows the problem in it's bare-bone form.
There are three textdisplay object in a single procedure.
- TextDisplay1 shows "CLICK MOUSE" and has a duration of 2000ms. It's time limit however is set to 5000ms. It accepts all mouse inputs but the correct response is a left click. It's end action is set to "none".
- TextDisplay2 shows a fixation cross and lasts for 3000ms. It does not collect responses
- TextDisplay3 is there to show us the values of RESP, CRESP and ACC for TextDisplay1 (implemented with an inline script)
If one makes a leftclick during the duration of TextDisplay1, TextDisplay3 shows that RESP was 1, CRESP was 1 and ACC also 1 - as expected.
But try clicking left after TextDisplay1 ends but before TextDisplay2 ends - in the interval from 2000 to 5000ms. If you do, you'll see that RESP and CRESP both have -null- values. This should not be so as we've set TextDisplay1's time limit to extend beyond it's duration, by all rights there should be a RESP value; not to mention a CRESP value!
the same thing happenes if one just waits for the entire 5000ms duration - RESP and CRESP both get null values.
And for the really bizzare thing: if you look at the data file generated, you'll see that RESP, CRESP and ACC for TextDisplay1 have the values one would expect. There is nothing wrong in the data file - it's only during runtime that one gets this strange behavior.
I'd like to use the values of RESP, CRESP and ACC at runtime but simply can't due to this kink.
Am I doing something wrong or is this a bug?
cheers
|
|
|
|
|
Forum Guru
Group: Forum Members
Last Login: Today @ 1:49:23 PM
Posts: 288,
Visits: 738
|
|
JurijD,
Thanks for posting your brief test program, that made the diagnosis easy. The problem is in your script line. Here is your original Inline1 (I added line breaks for clarity):
TextDisplay3.text = "Response : " & c.GetAttrib("TextDisplay1.RESP") _
& "" & "Correct : " & c.GetAttrib("TextDisplay1.CRESP") & "" _
& "Accuracy : " & c.GetAttrib("TextDisplay1.ACC")
As it turns out c.GetAttrib is working exactly as it should, and in this case you should use the object properties directly instead of the context attributes, e.g.,
TextDisplay3.text = "Response : " & TextDisplay1.RESP & "" _
& "Correct : " & TextDisplay1.CRESP & "" & "Accuracy : " _
& TextDisplay1.ACC
Here is why: The context attributes like "TextDisplay1.RESP" do not get set until a call to c.SetAttrib. If you look directly at the full script generated by E-Prime, you will see that this does not happen until after TextDisplay3.Run. This means that the context attributes are, indeed, null at the time that your inline script runs, but are set correctly before the c.Log at the end of SessionProc, which then stores the proper values to the data file. In general, E-Prime puts off setting the logging attributes until shortly before the c.Log at the end of a procedure, so it is not safe to use these attributes in the same procedure that generates the values. Once again, in this case you should instead use the object properties directly.
Hope that helps,
-- David McFarlane, Professional Faultfinder
|
|
|
|
|
Forum Newbie
Group: Forum Members
Last Login: 10/13/2008 7:30:54 AM
Posts: 4,
Visits: 24
|
|
Dear David,
thanks for your speedy reply & solution.
cheers
Jurij
|
|
|
|
