Important changes in E-Prime version 2.0.10.x

The E-Prime Production Release version 2.0.10.x introduced several useful features that were not available in E-Prime version 2.0.8.x. However, we recently discovered that some existing features (or their settings) have significantly changed since we published the E-primer. We will list those here below. In case you have decided to update E-Prime to version 2.0.10.x please read PST's documentation about this first. Please do not skip the issues we raise here: you will surely encounter some difficulties as soon as you start designing new or adapting existing experiments in version E-Prime 2.0.10.x (see here in case you upgrade an old experiment to an E-Prime 2.0.10.x file). Furthermore, when running experiments described in The E-Primer, you need to solve some of the issues described here. We are currently working on an addendum to our book that describes these changes. In the meantime, you can use the summary of the most important troubleshooting.

E-Prime 2.0.10.x files are not backward compatible

As soon as you start developing E-Prime 2.0.10.x experiments, you can't open them anymore in E-Prime 2.0.8.x. So, in case you need to collaborate with people using older versions of E-Prime it may be better to postpone updating. See also this link: http://www.pstnet.com/support/kb.asp?TopicID=5345

Furthermore, backward compatibility issues can arise when trying to downgrade E-Studio form 2.0.10.x to a 2.0.8.x. Even when completely uninstalling E-Prime 2.0.10.x, your computer will store information about the previous install (due to changes of the HASP licensing). This information will not allow you to re-install any old release except for 2.8.90a, which has been compiled for specifically this purpose (http://www.pstnet.com/support/kb.asp?TopicID=4998).

Default frame Size set to 75%

All new objects added to your experiment will automatically get a “Frame Size” of 75%. This likely introduced to be helpful for instruction screens with large images (not filling up the complete display and thereby reducing timing errors; see: https://support.pstnet.com/entries/24643453-2642-FEATURE-Default-frame-size-lowered-to-75-); however, it does imply more work in case you want to make use of the entire screen. To date, there is no option to change the default frame size yourself, so the only way to use full screen in objects is to manually adapt all E-Object’s you would like to have a different frame size.

Here are a couple of things you may want to verify before running the experiment:

• Did you set the background color of the Display correctly? Otherwise, the part of your screen not covered might be in a color different from the background color of your objects. This is how to change the background color of your display: Experiment Properties > Devices > Display > Default Background Color 
• In case your script refers to .X and .Y positions (e.g. using an Inline) of sub-objects in a Slide Object, those are now relative to the upper-left corner of your frame, not relative to the corner of your screen.

Of course, one useful strategy to cope with this is to create a master “template” object, like a slide, which has your personal preferences in terms of look, feel and critical timing predefined. Then, rather than creating each new slide from scratch, you can just copy (hand control and drag object) new versions of the slide. This way, your experiment will also get a more coherent look.

E-Prime 2.0 Professional users can change the Toolbox Defaults (right-click in Toolbox area > Toolbox Defaults). More information available here and here.

Windows dialog boxes do not show up due to display flipping

Windows dialog boxes called by InlineObjects, such as the MsgBox and the InputBox are excellent for debugging purposes or illustrating the principles of coding in E-Basic. However, they no longer appear by default always. That is to say: they still “work”, but often don’t show, and the user will find it difficult to click the invisible OK button of the invisible dialog. So an extra Space/Return may be needed to "click" the invisible OK button of the invisible dialogbox.

For Windows 8 users, there is no solution to this issue as of yet (PST is currently working on a custom PackageCall that will simulate a MsgBox). For others, the following will visually enable the dialog popups again:Experiment Properties > Devices > Display > Flipping Enabled > set to "No".

However, please note the following:

The use of flipping is recommended especially for larger displays to reduce the possibility of display tearing (when part of the new/old screen appear at the same time). (source)

So it might be better to get rid of your dialog boxes (e.g. instead of the InputBox, use the advanced input "echo" feature) and set Flipping back to Yes as soon as you are going to run the experiment in the lab.

PreRelease by default same as duration

The developers of E-Prime decided that it would be beneficial to reduce timing errors by setting the default PreRelease to "(same as duration)" rather than keeping it to the earlier default of 0 ms.

Here is some explanation on PreRelease:

PreRelease serves to eliminate the delay caused by the time it takes to set up the next object in an experiment. Using PreRelease allows the currently displayed stimulus to lend time to the following stimulus so that following stimulus can perform setup activities (e.g., reading data from a disk, getting the image ready in memory). Thus, when the second stimulus is scheduled to display, it is simply copied to the screen and any delay caused by setup activities is eliminated. (source)

And this is what the E-Prime recommends:

In most cases, using PreRelease on all objects is a good thing, and will allow for load time of objects following those with PreRelease set. However, in cases where an object is followed directly by an InLine with script (i.e., "If Stimulus.RESP = 1 then."), caution should be taken to limit or eliminate PreRelease. This is because, once the PreRelease time is reached, script from the InLine object will start processing. If the InLine is handling responses and the response has not been made, data collection can be affected. (source).

So, please check the following carefully:

• Set the PreRelease of the objects that precede InLines to 0, unless you have good reasons for doing it otherwise. In general avoid the use of InLine at timing-critical moments (e.g. near the onset of stimululi) altogether. However, if this is a necessity anyway, set the PreRelease of objects that precede InLine to 0.
• Do you send LPT data (e.g., EEG markers) using the OffsetSignalData method using InLines? Then also make sure you set the PreRelease of the respective object to 0. So in case you set the OffsetSignalData of a TextDisplay called TargetStim, make sure TargetStim has a PreRelease of 0. Otherwise (i.e., if PreRelease = same as duration), the OffsetSignalData will be triggered immediately after onset of the stimulus and no, or distorted, LPT pulses might be recorded. Of course, in many cases it is better to set a PreRelease because of timing accuracy. In those cases you might consider using the Task Events feature instead.

Objects are compiled at the beginning of procedures by default so content of attributes might not be updated correctly

Another feature that PST deems useful to improve timing-related aspects is the GeneratePreRun property of objects which are now automatically set to TopOfProcedure by the default value Inherit (similarly, GeneratePostRun is set to EndOfProcedure). That is, properties of objects are now loaded by default at the beginning of the trial, so as to avoid doing this at more time-critical moments (e.g., near a subliminal stimulus). However, if you update the value of attributes during a procedure using a c.SetAttrib statement this update does not affect any following objects, even though these objects might come with settings that depend on the updated attribute. Also, if the attribute was not available in the List before but is created by the InLine you will get a compiler error indicating that the attribute does not exist.

This is what E-Prime support says about this:

E-Prime 2.0 introduces the GeneratePreRun and GeneratePostRun properties. When these properties are set to TopOfProcedure, the .Load script generated by E-Studio will occur at the start of the Procedure. This provides the benefit of having all of the objects load their properties at a non- time critical portion of an experiment. Use of the BeforeObjectRun results in the same behavior that occurred in E-Prime 1.x, where the script for .Load is generated immediately prior to the .Run script generation of an object. Objects on a Procedure can customize this value or they can choose Inherit (default) which inherits the value from the Procedure. Using Inherit for the property value permits for easier changing of all object behavior on a Procedure by setting the desired script generation only on the Procedure.

When using the TopOfProcedure GeneratePreRun option, take care when using [attrib] references for any properties on the objects that are modified by c.SetAttrib calls on the Procedure. Doing so will successfully update the value of the attribute in the Context, but since the object has already performed its .Load operation, it will not take into account for the new value. (source)

So, please check the following carefully:

• In case you use InLine with SetAttrib statements, make sure you set the GeneratePreRun property of the object that referred to that attribute later in the procedure to BeforeObjectRun. For example, if there is an InLine object that contains the code c.SetAttrib "ExampleAttribute", "Show this", whereas the text of a TextDisplay1 later shows this value using an [ExampleAttribute] reference, set the TextDisplay1 Properties > Common > GeneratePreRun to BeforeObjectRun. It is also possible to change all objects under a single procedure to follow BeforeObjectRun logic: keep the default value of “Inherit” for everything but the properties of the Procedure itself. Then, changing the properties of the Procedure will enable BeforeObjectRun across all objects within the procedure. 

Saved by the Experiment Advisor?

If you are fortunate enough to have a professional version of E-Prime 2.0 and you stored your file in that format, some (but not all) of the issues before are automatically listed for you in the so-called Experiment Advisor available in E-Prime 2.0.10.x. If you only have the Standard License, the software package will be unable to help you assist with these problems automatically. Of course, you can also submit a support request at PST's website. We hope this blog helps you to deal with these potential issues if you decide to upgrade to 2.0.10.x.