Callbacks

This chapter describes the use of callbacks in XML Export. Callbacks allow the developer to intervene at critical points in the export process. Each heading in this chapter is a possible value for the dwCommandOrInfoId parameter passed to the developer’s callback.

The new SCCOPT_EX_CALLBACKS option allows developers to enable or disable some or all of these callbacks. See the Options documentation for details.

This section describes callbacks set in EXOpenExport. Read more about the callback procedure and the EXOpenExport function call in EXOpenExport.

A second callback function, DASetStartCallback, can provide information about the progress of a file conversion. See Data Access Common Functions for more details.

This chapter includes the following sections:

• EX_CALLBACK_ID_CREATENEWFILE

• EX_CALLBACK_ID_GRAPHICEXPORTFAILURE

• EX_CALLBACK_ID_NEWFILEINFO

EX_CALLBACK_ID_CREATENEWFILE

This callback is made any time a new output file needs to be generated. This gives the developer the chance to execute routines before each new file is created.

It allows the developer to override the standard naming for a file or to redirect entirely the IO calls for a file. This callback is made for all output files that are created.

These include all output text and graphics files that are created. However, it does not include the already open initial file passed to EXOpenExport, unless of course redirected IO is in use with a pSpec of NULL.

If redirected IO is being used on output files, this callback must be implemented.

For this callback, the pCommandOrInfoData parameter points to a structure of type EXFILEIOCALLBACKDATA:

typedef struct EXFILEIOCALLBACKDATAtag
{
   HIOFILE    hParentFile;
   VTDWORD    dwParentOutputId;
   VTDWORD    dwAssociation;
   VTDWORD    dwOutputId;
   VTDWORD    dwFlags;
   VTDWORD    dwSpecType;
   VTLPVOID   pSpec;
   VTLPVOID   pExportData;
   VTLPVOID   pTemplateName;
} EXFILEIOCALLBACKDATA;

• hParentFile: Handle to the initial output file with which the new file is associated. The dwAssociation describes the relationship. This handle is not intended for use by the developer. Set by caller.

• dwParentOutputId: Set by caller. The type of the parent file. This value is FI_XML_FLEXIONDOC_LATEST.

• dwAssociation: One of the following values:

  • CU_ROOT: For the initial output file.

  • CU_SIBLING: For new files that are not somehow owned by the parent file.

  • CU_CHILD: For new files (usually GIFs, JPEGs, or PNGs) that are embedded in the parent file.

  dwAssociation used in conjunction with dwOutputId can be used to segregate various types of files. For instance, the developer might want to place all GIFs in a sub-directory named GRAPHICS. Set by caller.

• dwOutputId: The type of the new file. This value is FI_XML_FLEXIONDOC_LATEST, FI_JPEGFIF, FI_GIF or FI_PNG.

• dwFlags: Reserved

• dwSpecType: IO specification type. See Data Access Common Functions for details about IO specifications.

  This member in conjunction with pSpec allows the developer to choose any location for the new file or even redirect its IO calls entirely. See Redirected IO for more details. When the developer receives this callback, the value of this element is undefined. Must be set by developer if this callback returns SCCERR_OK.

• pSpec: This field holds the IO specification of the output file to be created. pSpec points to a buffer that is 1024 bytes in size. If your application needs to set the specification of the output file, it may do so by either writing new data into this buffer, or by changing the value of pSpec to point to memory owned by your application. If pSpec is set to a new value, then your application must ensure that this memory stays valid for an appropriate length of time, at least until the next callback message is received, or EXRunExport returns.

  If the current export operation is using redirected IO, your application must create a redirected IO data structure for the new file and set pSpec to point to it. This pointer must stay valid until the structure’s pClose function is called.

  If your application sets dwSpecType to IOTYPE_UNICODEPATH, the specification must contain UCS-2 encoded Unicode characters.

  When your application receives this callback, the contents of the buffer pointed to by pSpec contain a proposed filename for the new file. When the SCCOPT_UNICODECALLBACKSTR option is set to TRUE, this filename is in Unicode. Otherwise, it is in single-byte characters. It is suggested, although not required, that this filename be used for the new file. Often the proposed filename will be referenced from within the output XML, so if the developer chooses a different one it may prevent consumers of the output from locating the files referenced from within the output.

• pExportData: Pointer to data specific to the individual export. In this case, always a pointer to either an EXURLFILEIOCALLBACKDATA structure or an EXURLFILEIOCALLBACKDATAW structure. The EXURLFILEIOCALLBACKDATAW struct is only used when the SCCOPT_UNICODECALLBACKSTR option is set to TRUE. These two structures are defined in EXURLFILEIOCALLBACKDATA / EXURLFILEIOCALLBACKDATAW Structures. Set by caller.

• pTemplateName: Not used in XML Export.

EXURLFILEIOCALLBACKDATA / EXURLFILEIOCALLBACKDATAW Structures

The EXURLFILEIOCALLBACKDATA and EXURLFILEIOCALLBACKDATAW structures are defined as follows:

typedef struct EXURLFILEIOCALLBACKDATAtag 
{
   VTDWORD   dwSize;
   VTBYTE    szURLString[VT_MAX_URL];
   VTDWORD   dwFileID;
} EXURLFILEIOCALLBACKDATA;

typedef struct EXURLFILEIOCALLBACKDATAWtag
{
   VTDWORD   dwSize;
   VTWORD    wzURLString[VT_MAX_URL];
   VTDWORD   dwFileID;
} EXURLFILEIOCALLBACKDATAW;

• dwSize: Set to sizeof(EXURLFILEIOCALLBACKDATA) or sizeof(EXURLFILEIOCALLBACKDATAW).

• szURLString / wzURLString: This parameter can be set by the developer to a new URL that references the newly created file. This parameter is optional unless the pSpec provided by the developer points to something that cannot be used as a URL (as when using redirected IO, for example). In that case, this parameter must be set.

  This string is written into any output file that needs to reference the newly created file, with appropriate conversions between single and double byte output. Because this parameter is a URL, it is assumed to be URL encoded. When used in conjunction with dwSpecType and pSpec, this parameter can be used to generate almost any structure or location for the output files, including things like writing the output files into a database and then using a CGI mechanism to retrieve them.

  The current size limitation is 2048 characters. If the size exceeds this limit, the URL will be truncated and rendered useless.

• dwFileID: Set by the product. This is used as a unique identifier for each output file generated. It may be used for an OEM-specific purpose.

Return Value

• SCCERR_OK: dwSpecType, pSpec and szURLString (or wzURLString) have been populated with valid values.

• SCCERR_NOTHANDLED: Default naming should be used.

• SCCERR_FILEOPENFAILED: Some error was encountered creating a new output.

EX_CALLBACK_ID_GRAPHICEXPORTFAILURE

This callback only occurs when an error is encountered exporting a graphic. It allows the OEM to customize their handling of this type of error. This callback does not occur for graphics exports that are successful. It also does not occur for graphics that cannot be converted due to the lack of an appropriate type of import filter. If the appropriate import filter is not present, EXOpenExport returns SCCERR_NOFILTER.

The pCommandOrInfoData field points to a structure of type EXGRAPHICEXPORTINFO:

typedef struct EXGRAPHICEXPORTINFOtag
{
   HIOFILE     hFile;
   VTLPDWORD   pXSize;
   VTLPDWORD   pYSize;
   VTDWORD     dwOutputId;
   SCCERR      ExportGraphicStatus;
   VTLPDWORD   pImageSize;
} EXGRAPHICEXPORTINFO;

• hFile: A handle to the current graphic output file. An OEM can substitute their own graphic by writing the desired graphic image to the beginning of the hFile (via an IOSEEK (hFile, IOSEEK_TOP, 0L), etc. The export function closes the file when control is returned from the callback. The contents of hFile on entry to the callback handler are unpredictable.

• pXSize/pYsize: Pointers to the dimensions of the image that would have been exported. An OEM can set and use these values to control the image size displayed by browsers. These dimensions are placed in the associated <img> tag.

• dwOutputId: The type of graphics file that was being created (FI_GIF, FI_JPEGFIF, or FI_PNG).

• ExportGraphicStatus: The error code from the operation that caused the graphic image conversion to fail.

• pImageSize: The maximum size for the image in bytes is filled in by HTML Export here (0 = no limit). If this callback is handled, on return the OEM should set this field to the size of the image the OEM created. This image should be no larger than the maximum size HTML Export entered into this variable.

Return Value

The callback handler should return SCCERR_NOTHANDLED unless the OEM has written an image to hFile in which case a value of SCCERR_OK should be returned.

EX_CALLBACK_ID_NEWFILEINFO

This informational callback is made just after each new file has been created. Like the EX_CALLBACK_ID_CREATENEWFILE callback, the pExportData parameter points to an EXURLFILEIOCALLBACKDATA or an EXURLFILEIOCALLBACKDATW structure, but in this case the structure should be treated as read-only and the dwSpecType, pSpec and szURLString (or wzURLString) will be filled in.

This callback occurs for every new file. If the developer has used the EX_CALLBACK_ID_CREATENEWFILE notification to change the location of (or to set up redirected IO for) the new file, the data structure echoes back the information set by the developer during the EX_CALLBACK_ID_CREATENEWFILE callback.

Return Value

Must be either SCCERR_OK or SCCERR_NOTHANDLED. Return value is currently ignored.