Having the Duration of a Slide being processed in InLine script set to anything other than "0" This common mistake is often seen when people go from doing automatic logging on an object (RESP, RT, etc.) to manually logging responses using an IsPending() method in an InLine following the Slide. Often, the person designing the experiment will have the correct script and conditions required to correctly process the script, but have not changed the Duration of the Slide to "0". Forgetting this simple step can lead to the object running its original duration without using the IsPending() method at all.
Setting object and sub-object locations using pixels instead of percentages This is not always necessarily a "mistake", but avoiding the use of pixel values for object and sub-object locations will allow your experiments to more easily transfer between different machines (if the need arises) which may be using different native resolutions. Using percentage of display values for object and sub-object locations is always encouraged.
Utilizing Slide property-dependent calculations (i.e., TotalDuration = Stimulus2.OnsetTime - Stimulus1.OnsetTime) without actually logging the property In a complex experiment with a large number of calculations taking place in InLine script, it is easy to lose track of things that are only done through the E-Studio User Interface, such as making sure that the Properties being used in calculations are actually being logged on the objects themselves. In the above example, the script is setting the TotalDuration variable equal to the difference between the OnsetTime of the Stimulus1 and Stimulus2 objects. However, if the Logging tab in the object's Property Pages do not have the "OnsetTime" Property checked for both of these objects, the OnsetTime properties will not be calculated and your TotalDuration variable will either be incorrect or will throw an error.
Not clearing the parallel port after writing to it A common mistake seen in many experiments where external device communication is being utilized. It is imperative that the port be at its neutral state (+/- 0v) before being written to (set to +~5v). TTL pulses can be "ignored" if the port is already set to +~5v when it is written to a second time. To clear the parallel port, a simple "WritePort *PortNumber*, 0" command can be used. In cases where a TTL pulse of a specific length is needed, the "Sleep" method will effectively wait a specified amount of time before clearing the port.
Creating a task using a Professional template that may be used by multiple sites with only a Standard license It is recommended that unless you are absolutely certain that all parties making modifications to the task also have E-Prime 2.0 Professional, that all tasks are created starting with the "Blank" or "Basic" template, instead of "Blank (Professional)" or "Basic (Professional)". To tell whether your task was created using E-Prime 2.0 Standard or E-Prime 2.0 Professional, save the experiment onto your machine. Once it is saved, the name of the experiment located at the top of the structure window will be followed by (Professional) if it was created in E-Prime 2.0 Professional, or will be blank after the name, meaning that it was created in Standard. Note that users who only possess an E-Prime 2.0 Standard license will not be able to open .es2 files created in E-Prime 2.0 Professional.
Changing the name of objects in the experiment and forgetting to change object name-based script Throughout the course of developing an experiment, names of objects, Lists, sub-objects, and Procedures are often changed to accommodate different necessities from the experiment. When changing the name of any object in E-Studio, always remember to also check all InLine objects, as well as User Script, for script that references specific object names. After changing an object name on the Procedure, the Feedback object will automatically update to the new name, but InLine objects and User Script will not.
Not completely deleting unused objects from the Unreferenced E-Objects list When deleting an object from a Procedure in E-Studio, this does not completely delete it from the experiment. Because E-Prime is able to call objects via script (see Insert A Pause Sample), those that are not located directly on a Procedure can still be used if located in the Unreferenced E-Objects section of the Structure window. However, because these objects are still subject to runtime errors, an object that was meant to be completely deleted from the experiment can cause compile errors because of invalid filenames, wrong file locations, etc.
Determining length of presentation of an object by measuring Onset to Offset In display timing-sensitive experiments, the best way to check timing is to do a test run where the timing properties are set to Time Audit Only or Standard Data Logging mode. Once these are set, many users initially believe that the display duration of an object can be found by calculating Object.OffsetTime - Object.OnsetTime. However, because of possible OnsetDelay of the following object, this value may be inaccurate. For an accurate determination of actual display timing of an object, subtract the OnsetTime of the object from the OnsetTime of the object following it. This will take into account any Offset/OnsetDelays and paint a more realistic picture of your display timing.
Referencing Sounds/Images/Movies located somewhere else on your machine (i.e. the desktop) in objects To allow for convenient portability of an experiment between multiple machines, it is recommended that all users place stimulus files in the same folder as the .es2 file referencing it. By doing this, you also eliminate the need for referencing an entire file path, since E-Prime will automatically recognize files in the same location as the experiment file.
Using PreRelease on an object which has an InLine directly following it The PreRelease feature in E-Prime allows time for objects to start processing, or "buffer", in the background while the object before is still being displayed on-screen. 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.
Not recycling objects throughout an experiment For experiments which require multiple blocks, or consecutive objects with text or images, it is often very time consuming to create many different objects which reference a specific picture, or have a section of text hard coded. As time consuming as creating them is, modifying 20 objects instead of one can be even more time consuming. By using attribute references "[..]" that point to attributes on a List, you can cut down the number of unique objects in an experiment and make your paradigms more easily modified.
Lack of indentation throughout InLine script By using proper indentation in InLine objects, you can make your script much more transparent. When scripting a conditional If.Then or Do While.Loop, always make sure the conditional action being taken (the action between "If.Then" and "End If") is indented by one press of the Tab button.
Declaring what should be a Global variable locally By declaring a variable in the User Script tab (can be accessed by using Alt+5 in E-Studio and selecting the "User" tab) you can create a global variable that can be referenced anywhere in the experiment and, more importantly, will hold value throughout blocks and are often used for keeping correct answer totals or block accuracy totals.
Use of "Match Desktop Resolution at Runtime" when running on multiple machines Although this option allows for easy editing and debugging of an experiment without having to worry about native display settings, care should be taken to keep display settings the same for all subjects when testing. Setting a specific resolution in the Display Device's Property Pages is encouraged to limit variability.
Creating multiple .es2 files for multi-session experiments instead of using Session-counterbalanced Block List a. For experiments where multiple sessions are required, the use of a SessionList counterbalanced by Session will replace the need for multiple .ES2 files which need to be opened for each session. By simply using the StartupInfo prompts, you can run different sessions based on the value entered for the Session prompt.