DMDX Help.


Instruction Keyword

<Instruction N1,N2,N3>
<inst N1,N2,N3>


variants:

<Instruction option>
<inst option>

options:

newline
nl
escape
esc
right2left


    Keyword to turn on automatic formatting so people don't have to guess where line breaks in paragraphs of text should occur.  N1,N2,N3 specify the left, top and right coordinates of a rectangle on the screen in the same fashion as other on screen rectangles are defined in DMDX (see  <graphic>) with the exception that the bottom coordinate (if specified) will be ignored.  Words in an item that this keyword occurs in (note there's no correlation between item number zero instructions and the <inst> keyword although they are likely to both be used in the same item) are specified in a word per frame sequence "like ", "this ", "where ", "each ", "word ", "is ", "frame ", "delimited " with a following space and DMDX automatically starts positioning frames at N1,N2 and adds the width of the previous frames across the screen and inserts line breaks when the word crosses the right coordinate (N3).  The newline (nl) option forces a new line at the end of the frame they occur in (so the next frame will be drawn at the left edge of the bounding rectangle) and the escape (esc) option escapes the frame it occurs in from <inst> positioning allowing <xy> for example to be used.  The right2left option is for use with fonts like Hebrew where words start at the right margin and progress leftwards (use of <XYJustification 4> being all but mandatory, see note below).  The right2left option also makes changes to the way <prose> operates, reversing the right and left arrows and making the text it emits contain \rtlch RTF control codes (the latter being necessary to get the punctuation marks on the left of the words).

   
<XYJustification 3> is a useful keyword to use with <inst> if more than one font or bitmaps are to be included in the item as it will line up the bottoms of the frames up instead of the tops as the default justification would (you'll want to make sure the top coordinate is a bit lower on the screen as that will be the bottom of the first line of instructions).  Note that in order to get the base lines of the fonts to line up you're probably going to have to include spaces in the smaller font frames that are in the larger font size.  Large bitmaps might be kind of entertaining but hey.  Also, note that while <XYJustification 3> and <XYJustification 0> work with <inst> <XYJustification 1> is positively toxic (same probably goes for <XYJustification 2> but no one's ever used it let alone me so it's untested but assumed to be bad).  So if you're using <XYJustification 1> to position bitmaps nicely you're going to have to toggle back to <XYJustification 0> or <XYJustification 3> for <inst> use.  And then of course if you're using <inst esc> to position bitmaps then you'll have to be doing that toggling in the item from frame to frame as conditions change...

    Note that while the coordinates are all technically optional you're really going to need to specify the right N3 coordinate otherwise words will be truncated by the edge of the screen.  Also note that once the coordinate specifying form of this keyword occurs in an item it's active for the whole item, there's no way to have two different rectangles of text in one item and it is only possible to have a frame not subject to <inst>'s formatting by including <inst esc> in it.  Even if the <inst> is in the last frame of the item all frames before it not escaped will still be affected.  And you really shouldn't be using things like feedback or more specifically <ZillionTypedResponses> to gather responses as <inst> will be interfering with all that text formatting too (although the upcoming <prose> keyword is designed to work with <inst>).  If you need to combine them do so in separate items and continue from the first to the second and have the second not erase the screen from the first item (along with the usual <fbocb> to not erase stuff as typing is happening and so on):

<ep> <vm desktop> <zil> <ztr> <ntl> <cr> <fbocb> <eop>
0 <inst .1,.1,.8> "complicated ", "instructions ", "for ", "typing ", "in ", "the ", "following ", "item" c;
+1 ! "Type:" * ;

    There are several rather unobvious features to using right to left fonts in DMDX. prior to version 4.3.0.0  While the GDI portion of Windows that actually renders text in DMDX is aware of right to left fonts and will reverse the letter order so the display renders correctly it can only do that for individual requests and when there are font changes or formatting changes DMDX must make multiple requests for a given frame to be rendered.  For example say the following was actually in a right to left font "right to left" with no formatting it's one request from DMDX and GDI will in fact render "tfel ot htgir".  However if we say bold the "to" it's now three requests and in versions of DMDX prior to 4.3.0.0 we'd get "htgir ot tfel".  Worse, when you go back and edit something in Word even though the formatting is uniform across the string Word will render it in two sections so DMDX's rendering would be faulty.  To save the end user from these problems I modified DMDX in version 4.3.0.0 to parse the right to left codes in the RTF and so on.  Prior to that to get around this the right2left option was added so the following can be used:

0 <xyjustification 4> <inst .2,.4,.9> <inst right2left>  "right ", "to ", " left";

    Note that if you edit either of those three words (in Word at least) the word will be scrambled when DMDX renders it in versions prior to 4.3.0.0.  The solution there is to just retype the word from scratch in one edit, at least you don't have to retype the whole sentence...

 



DMDX Index.