listDevices fails when Microsoft Nano transceiver is connected

[GoogleCodeExporter]

What steps will reproduce the problem?
1. connect Microsoft Nano transceiver
2. call listDevices
3.

What is the expected output? What do you see instead?

I expect to get an array of devices instead an exception is thrown:

Exception in thread "main" java.lang.Error: iconv failed
    at com.codeminders.hidapi.HIDManager.listDevices(Native Method)

What version of the product are you using? On what operating system?

hidapi-1.1 / MacOS X 10.7.5/ JDK 1.7 Oracle

Please provide any additional information below.

Code:
ClassPathLibraryLoader.loadNativeHIDLibrary();
HIDManager manager = HIDManager.getInstance();
HIDDeviceInfo[] deviceInfos = manager.listDevices();

Device Information:

Microsoft® Nano Transceiver v1.0:

  Produkt-ID:   0x0745
  Hersteller-ID:    0x045e  (Microsoft Corporation)
  Version:   2.52
  Geschwindigkeit:  Bis zu 12 MBit/s
  Hersteller:   Microsoft
  Standort-ID:  0x04100000 / 2
  Verfügbare Stromstärke (mA):    500
  Erforderliche Stromstärke (mA):  100

Original issue reported on code.google.com by robertsc...@gmail.com on 25 Jan 2013 at 9:00

[GoogleCodeExporter]

could this be a problem with the registered symbol in the device name?

Original comment by robertsc...@gmail.com on 28 Jan 2013 at 11:14

[GoogleCodeExporter]

I have this same issue with OS X 10.7.5, but I don't think it's related to just 
that USB device.  I am attempting to access a USB shipping scale and get the 
same results...but it happens any time it's just trying to find the devices - 
if the scale is connected or not.

I am using the included native library...any help would be greatly appreciated.

Original comment by kvanstr...@gmail.com on 18 Mar 2013 at 8:30

[GoogleCodeExporter]

I've figured out the source of the error.  In jni-impl/hid-java.cpp, there is a 
function that appears to convert an error message from wchar_t to utf8 
encoding.  The iconv fails to convert the character encoding, and this throws 
the error we're seeing.

I've implemented a workaround for my application that seems to work fine, but 
I'm not sure of any consequences. I commented out the section that tests for an 
error in conversion, in hopes that I could still see whatever error message it 
was trying to give me.  After this, I clearly never got an "iconv failed" 
error, and I still saw and handled IOExceptions correctly.

Here's a paste of what I did (from line 70 in hid-java.cpp):

int nconv = iconv(cd, &uval, &ulen, &u8p, &u8l);

/* *** Commented to prevent "iconv failed" error

    if(nconv == (size_t)-1)
    {
        iconv_close(cd);
        free(u8);
        jclass exceptionClass = env->FindClass("java/lang/Error");
        if (exceptionClass == NULL) 
        {
            // Unable to find the exception class, give up.
            assert(0);
            return NULL;
        }
        env->ThrowNew(exceptionClass, "iconv failed"); 
        return NULL;
    }
*/
    *u8p='\0';

    iconv_close(cd);
    return u8;

Original comment by meyerdav...@gmail.com on 12 Jul 2013 at 3:48

[GoogleCodeExporter]

Third party reported similar behavior on an OS X 10.8 install. 
(http://code.google.com/p/fcd-spectrum/issues/detail?id=4) Doubtful this is 
caused specifically by the Microsoft Nano Transceiver.

Original comment by cjrit...@gmail.com on 7 Sep 2013 at 2:47

[GoogleCodeExporter]

I am having the same issue and i downloaded all of the files and changed the 
right file, but now i dont know how to recompile it as a .jar file so that i 
can use it in my program!! Can anyone tell me how to make an updated .jar file 
with these changes in them?

Original comment by willingh...@gmail.com on 8 Jan 2014 at 4:30

[GoogleCodeExporter]

If anyone is still having issues, I was able to get around mine by changing the 
following line:

47        iconv_t cd = iconv_open ("UTF-8", "WCHAR_T");

to:

47        iconv_t cd = iconv_open ("UTF-8", "UCS-4LE");

in file "javahid/jni-impl/hid-java.cpp". I was using a standard wired Xbox 360 
controller and the copyright symbol (the very first character) was the issue 
when getting the manufacturer string. I changed to using "UCS-4LE" because the 
underlying hid api uses the "kCFStringEncodingUTF32LE" key to get the string 
for the HID device info and UCS-4LE seemed like the closest thing to that and 
it worked! Also, I took the byte data and printed it directly in a Python shell 
using unicode and it printed correctly, so I needed something to get unicode 
characters 4 bytes wide (or 32 bits) in Little Endian format.

Original comment by smakat...@gmail.com on 31 Mar 2014 at 4:54