L_LTFIL_API L_INT EXT_CALLBACK L_SetFilterHeartbeatCallback(pCallback, pUserData)
Sets the callback used for tracking and aborting long-running operations.
Your callback function that fires whenever a filter heartbeat occurs.
Void pointer that you can use to pass one or more additional parameters that the callback function needs.
To use this feature, assign a value to a variable or create a structure that contains as many fields as you need. Then, in this parameter, pass the address of the variable or structure, casting it to L_VOID *. The callback function, which receives the address in its own
pUserData parameter, can cast it to a pointer of the appropriate data type to access your variable or structure.
If the additional parameters are not needed, you can pass NULL in this parameter.
|SUCCESS||The function was successful.|
|< 1||An error occurred. Refer to Return Codes.|
LEADTOOLS load file functions contains the FILEREADCALLBACK. It is used to monitor the progress of loading images by calling L_LoadFile or L_LoadSvg2.
FILEREADCALLBACK is quite suitable for raster images: the filter (PNG or TIF, for instance), can parse the image file structure quickly and start to send one or more scanlines to the callback quickly. Consequently,
FILEREADCALLBACK events will start to occur shortly after
LoadSvg is called. The application can use
FILEREADCALLBACK to show a progress bar to allow the user to monitor and potentially abort the load operation.
FILEREADCALLBACKdoes not work well with complex document file formats such as DOCX and XSLX. Their complex structure requires significantly more time to parse the file structure. The first scanline generated and sent to
FILEREADCALLBACKmay not occur until well after
LoadSvgwas called. The amount of time required for loading depends on the source file itself. For a very complex document file such as a very large XLSX spreadsheet with thousands or millions of rows, the time can be many seconds or even minutes. Moreover, file structure parsing usually occurs by calling L_FileInfo (whether called directly by the user, or internally by
LoadSvg), none of which invoke
For complex documents, using
FILEREADCALLBACK to allow the user to abort long load operations is not feasible: the callback will occur at the very end of the operation after all the necessary data has been parsed. A significant amount of time could have elapsed since the original
LoadSvg was called. Instead, the application can use L_SetFilterHeartbeatCallback to monitor and abort very long operations. FILTERHEARTBEATCALLBACK occurs at the beginning of
L_FileInfo, and then again periodically during this function and
LoadSvg, allowing the user to abort the current operation if desired.
In other words, aborting a filter operation does not throw an exception. Instead, the application should check the returned object as described above to detect when the user aborted.
Some applications require all load operations that take more than a certain time to be aborted (for instance, a web server using LEADTOOLS to load and return images in a web method). This server may require that no operation running within the web method can take more than 2 seconds. When this occurs, the operation should be aborted, and the work delegated to a dedicated thread or process outside of the web service worker thread.
L_SetFilterHeartbeatCallbackcan be used to install a callback that tracks the time and aborts all the operations taking more than the allocated time. Or,
L_SetFilterTimeoutcan be used to set a global timeout interval for all get information and load operations. This function uses
L_SetFilterHeartbeatCallbackinternally to install a handler that can take care of aborting long-running operations automatically.
Currently filter heartbeat and timeout is only supported for the following file formats:
Win32, x64, Linux.
Medical Web Viewer .NET
.NET, Java, Android, and iOS/macOS Assemblies
C API/C++ Class Libraries