"String missing" error on the signature capture window
The "String Missing" error occurs when the signature capture component has a problem loading localized strings.
The strings should be in 'MUI' files in language specific sub-folders of \Program Files\Common Files\WacomGSS (or \Program Files (x86)\Common Files\WacomGSS on Win64).
An uninstall/reinstall of the product (SignPro and/or Signature SDK) should fix the problem.
To be on the safe side, after uninstalling the product(s), check that the "...\Common Files\WacomGSS" folder and all subfolders have been removed.
"Unsatisfied Link" when compiling Java application - no flsx.jar in library path
When trying to run a Java application based on the Signature SDK you may encounter the following error:
"Exception in thread "main" java.lang.UnsatisfiedLinkError: no flsx in java.library.path"
There are two likely solutions for this.
1. Re-run the installer and include the correct components
Re-install the SDK and when the "Custom Setup" window appears make sure you select the Java components, 32 or 64 bit as appropriate for your system.
If you are running Windows 7 or 8 then you probably need the 64-bit components.
However if you are using a 32-bit JDK then you will need the 32-bit components.
The example screenshot below shows the 32-bit Java and .NET components being installed for a 64-bit SDK.
2. Edit java.library.path in your Eclipse project so that it points to the installed flsx.jar
The flsx.jar file for the Signature SDK is installed as follows:
- 32-bit components: C:\Program Files (x86)\Common Files\WacomGSS
- 64-bit components: C:\Program Files\Common Files\WacomGSS
Please see these Web pages for instructions on setting the java.library.path in Eclipse:
Automation server can't create object
This probably occurs because you have not installed an SDK (Signature or STU).
Similar errors may occur if you have compiled your application for a 32-bit CPU but installed the 64-bit SDK components - or vice versa.
SDK components must be installed on any machine running the SDK software and the DLL must correspond with the target architecture of your application.
The only exceptions to this are:
- When using SxS installation with a C# or Java application built with the STU SDK
- When using a Java applet with the STU SDK
Tablet Error (code 101) when trying to capture a signature
There is a known issue with HTML scripts which have been downloaded over the Internet or received via email.
Windows recognises them as a potential security threat and places a block on the file itself. The block can be seen by right-clicking on the file name in File Explorer and selecting properties as illustrated in the screenshot below.
There are 2 solutions:
The easiest one is simply to click the "Unblock" check box, click the "Apply" button and restart the browser.
Alternatively you can edit the file with a text editor such as Notepad and save it with a different file name - the process of saving it with a new file name removes the block. Note that simply renaming the file does not unblock it.
Capture returned 101 - Tablet Error when using the 540 in serial mode
When trying to capture a signature from the STU 540 in serial mode using the on-board ROM images the following error message appears:
Capture returned: 101 - Tablet Error
Please take into account the important factors listed below.
1. Upload the image
Before attempting to use the 540 in "Signature Mode" (i.e. on-board images) at least one capture window image must be uploaded using the Signature Mode Image Uploader.
For further details see STU-540 Operating Modes.
Please note that the DemoButtons test program uploads its own on-board images which will overwrite any that have already been uploaded.
If you upload one or more images with the uploader and then run DemoButtons in "Signature Mode" you will have to upload the original image(s) again to make your application work.
"Signature Mode" cannot be used with an evaluation licence so make sure that you have specified a production licence in your code.
3. Configuration Settings
The values which you specify in your configuration file (or in the API properties) must exactly match the values which were used when the image was uploaded.
There are three ways of specifying the configuration values for "Signature Mode":
- Specify the path name of the configuration file and the image number which you want to use in the code, e.g.
dc.SetProperty("stuSigModeConfig", "D:\\Signature SDK\\HTML\\STU-config.config, 1");
- Specify each individual property relating to the image in the application code, e.g.
dc.SetProperty("stuSigModeScreenNum",1); dc.SetProperty("stuSigModeWhen",1); dc.SetProperty("stuSigModeOK","OK"); dc.SetProperty("stuSigModeClear","Clear"); dc.SetProperty("stuSigModeCancel","Cancel"); dc.SetProperty("stuSigModeFontName","Verdana"); dc.SetProperty("stuSigModeFontSize",10);
- Specify the path name and image number of the configuration file in the registry in a string value named stuSigModeConfig as illustrated below.
For 32-bit applications on a 32-bit PC or 64-bit applications on a 64-bit PC the registry values should be in HKEY_LOCAL_MACHINE\SOFTWARE\Florentis\sd.
For 32-bit applications (e.g. Internet Explorer) on a 64-bit PC they should be in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Florentis\sd.
If any doubt please put them in both locations and create the "sd" key if it doesn't already exist.
COM exception - bitmap not in a suitable format
This can occur if your signature image is not big enough to hold the encoded data.
You can prove this by temporarily removing the RenderEncodeData flag. Then you should not see the error.
If you increase the image size the problem will probably be resolved.
Failed to retrieve a COM class factory for component with CLSID...class not registered
The full error message is normally much longer than the above and is similar to the following:
"Retrieving the COM class factory for component with CLSID (2000D7A5-64F7-4826-B56E-85ACC618E4D6) failed due to the following error: 80040154 - class not registered. "
This error can be caused by compiling a .NET program for AnyCPU and trying to run it on a machine where only the 32-bit DLL has been registered.
This can happen with the STU or the Signature SDK.
The solution is either to change AnyCPU to x86 (the STU SDK only registers the 32-bit DLL) or to register the 64-bit DLL manually.
To register the 64-bit DLL manually please proceed as follows depending on which SDK you are using.
Install the SDK
Start a command prompt with Administrator privileges
Go to the directory where you have installed the SDK's DLL i.e. wgssSTU.dll.
Note that the installer puts the DLL in C:\Program Files (x86)\Wacom STU SDK\COM\bin\Win32 (or C:\Program Files\Wacom STU SDK\COM\bin\x64 on a 32-bit PC) but we recommend installing it somewhere else for the purposes of development and redistribution.
Run the following command from your elevated prompt:
If you ran the 64-bit installer when you installed the SDK then the above COM class factory should not occur because the 64-bit installer registers the 64-bit DLLs.
If you ran the 32-bit installer, or the 64-bit installer without selecting the 64-bit components, then proceed as follows:
- Run the 64-bit installer and select the 64-bit components - this will register the 64-bit DLLs.
If for any reason you still want to register the 64-bit DLLs manually then start a command prompt with Administrator privileges and proceed as follows:
C: (if needed) cd \Program Files\Common Files\WacomGSS regsvr32 FlSigCapt.dll regsvr32 FlSigCOM.dll regsvr32 FlWizCOM.dll
Florentis assertion failure
This can happen on Windows 10 and is probably because you are using an old version of the SDK which is not compatible with Windows 10.
This error was fixed in release 3.2.0 of the Signature SDK which was released in September 2015.
To download the latest version please select "For signature" at https://developer.wacom.com/developer-dashboard/downloads
GDIplus error: Win32Error
This error could be caused by outputting to a file on a read-only folder such as "C:\Program Files".
- Avoid writing to a read-only directory (this might even be the directory in which you are running your application)
- Specify a full path name
- Make sure the target folder itself exists
For further information please see Microsoft's list of Windows error codes
Primary reference Florentis.InteropFlSigCapt could not be resolved
The full message is:
Primary reference Florentis.InteropFlSigCapt could not be resolved because of an indirect dependency on the .NET framework assembly
This can happen if you build a .NET application targeted at framework 3.5 and try to include the interop DLLs from the Signature SDK which are built for 4.0.
The solution to this is to add references to the DLLs themselves and not the interop files.
As illustrated in the Reference Manager screenshot below references have been added to FlSigCOM.dll and FlSigCapt.dll – Visual Studio will then generate its own interop files for your target framework.
Remove any existing references to WacomGSS or Florentis interop files and then add the two shown with ticks below.
In the example below the target CPU is set to x86 which is why the DLLs have been selected from "C:/Program Files (x86)/Common Files/WacomGSS" and not "C:/Program Files/Common Files/WacomGSS"
Strong name validation error
This can be caused by using an out-of-date Interop file reference in the Visual Studio solution.
Make sure the latest SDK is installed, then change the Interop reference on the solution so that it points to the relevant Interop file from the appropriate SDK installation folder as detailed below.
There is only one 32-bit interop file for the STU SDK - C:\Program Files (x86)\Wacom STU SDK\COM\bin\Win32\Interop.wgssSTU.dll
All the 32-bit interops for the Signature SDK are in C:\Program Files (x86)\Common Files\WacomGSS
There is only one 64-bit interop for the STU SDK and this is C:\Program Files (x86)\Wacom STU SDK\COM\bin\x64\Interop.wgssSTU.dll
All the 64-bit interops for the Signature SDK are in C:\Program Files\Common Files\WacomGSS
The capture window on the STU 540 takes a very long time to appear when used serially
When trying to capture signatures from the STU 540 in serial mode (e.g. over RDP) the capture window takes several minutes to be displayed
If you want to capture signatures from the STU 540 in serial mode you must use the on-board ROM images. This is known as "Signature Mode".
For further details of how to implement "Signature Mode" please see the STU-540 Operating Modes.
STU 540 display remains blank but an "Evaluation" signature window appears on PC monitor
This situation can occur when a signature application tries to capture a signature from an STU 540 assuming that it is in HID mode, whereas in fact it is in serial mode.
The STU 540 can operate as a standard USB HID device or serially via a virtual COM port. To verify whether a 540 is in HID or serial mode there are two main options:
- Open up Device Manager on your PC and look under "Ports (COM & LPT)" or "Universal Serial Bus Devices". If the first of these sections shows an entry for "USB Serial Port (COM5)" (where COM5 could be any COM number from COM3 upwards) then the 540 is in serial mode. For example see the screenshot below which shows two 540s, the first one in serial mode on COM5 and the second in HID mode:
- Read the guidance on STU Serial Connection and use getSerialPorts to see if a virtual COM port is displayed as follows:
D:\SerialTestUtils>getserialports COM5 virtual
The above indicates that the 540 is connected to virtual COM port COM5 i.e. it is operating in serial mode.
Normally 540s are delivered from the factory in HID mode but occasionally customers find that they are in serial mode.
Special configuration is required in the signature application if the 540 is to be used serially.
For more information on this please see the STU 540 Installation Guide and Uploading images to the 540
If you want to use the 540 in standard HID mode (this is the most common scenario) and the serial test utilities mentioned above indicate that it is in serial mode then you will need to use the serial2hid tool to convert it back to HID.
e.g. serial2hid COM4 128000