There are three sections in the script file that apply to automation in particular:

[EventNames]

There are three events that can be signaled by the printer:

CommandsProcessed

DocumentSpooled

DocumentCanceled.

If you are changing printer settings between print jobs, you must set the CommandsProcessed to the name of an event you have created and are waiting on in order to know when the printer has finished reading the script file and it is now safe to move on and change the values in the script file for the next print job.

This is to ensure that each job is matched with the appropriate settings (thread-safe batch printing in a multi-thread multi-process environment). It is the responsibility of the printing application to create and block the event. The printer will automatically signal the event when it has finished reading the script file.

The DocumentSpooled and DocumentCanceled events are signaled by the printer when the print job has finished being spooled successfully or has failed to spool, respectively.

Document Spooled, DocumentCanceled Events

These events do not mean the conversion process has completed, unless the printer is configured to "Print directly to the printer".

 

[User variables]

Use these variables to store information you wish to pass on to your code or to use as parameters to any program which you have attached to any one of the Run events. There are 10 user variables available to use, Var0 - Var9. When referencing these variables as a parameter, they require the macro expansion syntax - $(Var0)-$(Var9).

[User Exit 1], [User Exit 1.x64]

This user exit is invoked when an application starts to print and gives you an opportunity to augment the information or gather additional information that needs to be part of this conversion process. For example, you could prompt for fax information or have the user select from a preset list of locations to store the file.

This user exit calls a function contained in a DLL that you have produced. The [User Exit 1] section is used by 32-bit applications. The [User Exit 1.x64] is used on 64-bit operating systems. If you are using the User Exits and need to support both 32-bit and 64-bit operating systems, you will need to provide both a 32-bit and a 64-bit version of your DLL.

 

[User Exit 1]

Path=C:\Test\MyUserExit.dll

Function=GatherFaxInformation

FunctionEx=

 

[User Exit 1.x64]1

Path=C:\Test\MyUserExit64.dll

Function=GatherFaxInformation

FunctionEx=

 

The functions in the DLL have the following prototypes:

BOOL APIENTRY MyUserExitFunction(HANDLE hCommandFile,LPCSTR pszDocument)

 

BOOL APIENTRY MyUserExitFunctionEx(HANDLE hCommandFile,

                                   HANDLE hPrinter,

                                   DWORD dwJobID,

                                   LPCWSTR pwszDocument)

 

The first argument is a file handle that you can use with the WriteFile Win32 API to write control strings (see Using control strings). Be sure to end each line with an end of line (\n) character.

Writing control strings to the hCommandFile allows you to change the printer settings, set user variables, or even cancel the job before it is queued.

The standard prototype MyUserExitFunction receives the document name as its only other argument.

The extended version, MyUserExitFunctionEx, receives the printer handle and job identifier, in addition to the document name (in Unicode string format).

If either function returns FALSE, the job is canceled and any Run At events are not executed. If you want any Run At events to execute, use a control string to set CancelJob to 1, and return TRUE.

The user exit DLL is unloaded as soon as the call returns.

For back-end processing and workflow integration, you can use the Run At events to launch applications, call DLL functions, or signal events. For more information, see the Using Run Commands to Call DLL Functions topic.

Note:

If both MyUserExitFunction and MyUserExitFunctionEx are specified in the INI file, the MyUserExitFunctionEx takes precedence.