Intermediate Publish

Generating an .i3pub file is a means of breaking the publishing processes into two stages so that a handler can be assembled, packaged into an intermediate format and saved to disk, then transferred and published on an entirely different server. This intermediate file contains the .class file, the configuration data for DS, the audio prompt data, and a copy of the .ihd file, along with everything else needed for publish.

When this process is started, the user will be prompted for a directory into which the intermediate file will be saved. After making this selection, the publish dialog box will appear which will prompt the user to enter a handler description and handler activation data. Interaction Designer then converts the handler, compiles the code, and places everything needed for complete publish in a file with the extension .i3pub in the specified directory.

When you select Generate .i3pub File from the File menu, the following dialog box appears:

Enter a description of the handler in the text window provided. If you want the handler to become active as soon as the publish is complete, select the Activate Handler check box at the bottom of the dialog box. If Activate Handler is selected, you must also select whether the handler is going to be a Primary or Monitor type handler. Follow these links to review the differences between Primary and Monitor handlers.

When generating an .i3pub file for a subroutine, the dialog box looks slightly different than for a handler:

Add the appropriate notes in the text window and select whether or not you want the subroutine to become active immediately upon publish, just as you would with an event-initiated handler. Also, you must select a category for the subroutine.

It is important to note that selecting the activation status of a handler will change any activation status the handler may have previously had. For example, if a handler was Active Primary before, and someone republishes it and selects Active Monitor, then that handler will be changed from Primary to Monitor. Interaction Designer attempts to help the user here by setting the default to the condition that existed before -- if a previously published handler was active, then the checkbox will appear already checked; if it was Primary, the Primary option will be set, etc. If the handler had not been published before, then it defaults to Inactive.

This "activate on publish" feature also applies to batch publish. Batch publish allows a user to create a text file listing .ihd files to be published. The user can then start Interaction Designer with a command line parameter (/publish:{filename}) and Interaction Designer will open the text file, then open each .ihd file listed and publish it. The user can also optionally specify the activation status in the text file as well. Consider the following example batch publish file:

FirstOne.ihd

SecondOne.ihd | Primary

ThirdOne.ihd | Monitor

FourthOne.ihd

In this example, after FirstOne is published, there will be no change to its activation status (if it was Primary before, it's still Primary, etc.) SecondOne will be set Active Primary, ThirdOne will be set Active Monitor, and FourthOne will have no change to its existing activation status. If FirstOne or FourthOne had no activation status before (i.e. first publish on this server), then the default status will be Inactive.