In case the application is running on the same system where the pad is connected, we can access the signature pad by USB. But in case the application can´t have a direct access to the USB device, which is the case by RemoteDesktop and Citrix, we are forwarding all device requests to our Client Component. This Component will execute the requests and will send the results back to the server application.
We designed the remote component/layer in the way, that the main application don´t need to be modified in case the signature device is not local connected. Therefor we are tunnelling our device-communication between our SOPAD.dll (High Level Pad Comunication) and the SOPADCOM.dll (USB-Level), which means we are replacing the normal SOPADCOM.dll on the server with mediator version. This version takes care that the signature pad request will be forwarded to the client (by TCP or Citrix), where the local SOPADCOM.dll will perform the request.
Which Type of communication is used dependents by the DLL Version which is used from the Application. This means you need already to decide by the installation which communication type you want to use.
If you have problems with finding the signature device the reason can be a police which blocks custom virtual channels. In case of problems, check out the Event Viewer for possible blocking events.
To fix the issue, you need to configuring the Citrix virtual channel allow list policy. You can either do this in the Studio:
or inside the registry
VirtualChannelWhiteList = "=disabled="
Virtual channel allow list now enabled by default | Citrix Blogs