DMDX Help.


Chain Keyword

<Chain [option] text>

option:
preservevm

    Parameter and switch to chain another item file. text is interpreted to be an item file in the same directory as the current item file, if no extension is provided .rtf is appended to the name. If another directory is desired a path relative the current item file's path must be used.  If you want to use non-ASCII characters in the name of the item file to chain you must be using DMDX 6.2.0.0 or later and text must be in quotes (it's also a really good idea to turn the Unicode option on) and as of 6.4.0.0 the quotes are no longer necessary (unless your file name has spaces in it) as Unicode outside of quote is preserved as UTF-8.  There is only one possible option at this time assuming you're using version 5.2.2.0 or later and that you're using the Direct3D renderer and that is preservevm and when present DMDX attempts to keep the display static and rings no bells so as to appear as if only one item file is executed.  Note that this new option assumes you have in fact used the same video mode in the chained item file, I make no predictions as to what will happen if you have a different one...  As of version 5.3.1.10 of DMDX preservevm can be used with machines using the DirectDraw renderer, at the very least it suppresses the bells as the files are chained and on some systems provides an experience similar to the Direct3D one where the only clue an item file is chaining is the time taken to load the new file.  As of version 6.3.0.2 it would appear that preservevm now preserves the state of the cursor across chains, so if you use <2Did mouse> for instance that turns the cursor on and in the chained item file no longer use it you're probably going to have to use <mip cursoroff> to turn the cursor off for the second item file, looks like I fixed it in 6.3.1.1 however.

     The new item file will not be executed until the current item file finishes or terminates with the <Last Frame> keyword. All devices are closed and the data is automatically saved and the new item file is run as if it had been run manually thus allowing changes in input devices and scrambling parameters for instance. Use of the Subject ID is highly recommended as tracking a subject's data across data files could be challenging otherwise.

    Note, use of <SkipDisplay> in a last frame item prior to version 5.0.0.0 of DMDX would result in the job being aborted and any data not being saved.  This has now been rectified.

    Also note that unless preservevm has been used between item files DMDX is going to shut the screen down and some displays will either flick back to the desktop or the DMDX dialog display momentarily, not much we can do about that (assuming preservevm is out of consideration of course).  But some other displays switch back to a previous item's display and here we can actually do something.  Putting an <EraseAll> in the last frame will clear all the back buffers (that have previous item's displays still in them) and fixes the problem because even if the video drivers display another buffer at least it will be blank (or the last item's display).

    See <loadcounters> for details on setting up a re-entrant item file using <chain> .

    Note that the Syntax check prior to version 6.3.1.2 of DMDX can be a bit freaky when chaining item files as it doesn't stop at <lastframe> items, it continues to the actual end of the item file before then chaining to whatever the last chain specified (meaning if you've got more than one possible chained item file things will not be proceeding as one might expect).  On top of that if your item file sequence chains back to a previous item file infinite loops are squarely in play so in version 6.3.1.2 I just stopped the chain keyword from doing anything in a syntax check which means if you need to do a syntax check with chained series of item files you'll have to check them individually.  Prior to 6.3.1.2 I tended to use Diagnostic runs to syntax check chained item files and I also tend to use Diagnostic Branching as well as any time I'm using more than a simple chain of item files (ones that start with one item file and then proceed linearly through a given sequence with no repeated files) I'm usually also branching like a SOB and in the Introduction (the absolute mother of all chained item files) I even go to the bother of detecting when a diagnostic run is in place and use macros to not ask to repeat a given section as in a diagnostic run the RT is always going to be positive and the value of the item's number.  I do that by specifying a really low subject timeout and if I detect an RT above that I set a macro up to not ask questions otherwise it sets it up to ask questions:


+77 <t 10> <nfb> * <! detect diagnostic branching>;
~1 mb++ <bi 3, lastrt .EQ. 77>;
~1 mb+<bic -777>+ <! only offer repeat when not diagnostic>;
~3 <nfb 0> <t 4000>;

    The introduction uses item 777 to mark the start of sections that can be repeated, later on at the end of those sections the items that would cause an infinite loop in diagnostic mode just use macro B that is either capable of branching back to the most recent item 777 or not:


+1 <nfb> "Would you like to repeat that sequence?" * ~b;

   



DMDX Index.