View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006549 | JEDI VCL | 00 JVCL Components | public | 2017-03-07 00:26 | 2021-10-09 19:39 |
| Reporter | davedelage | Assigned To | |||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | feedback | Resolution | open | ||
| Product Version | 3.48 | ||||
| Target Version | Fixed in Version | ||||
| Summary | 0006549: JvHidDeviceController fails | ||||
| Description | JVCL version actually 3.49 but problem exists in earlier version. Compiling example SimpleHidWrite using Rad Studio 2010 on Windows 8.1 and it works as advertised. Copy SimpleHidWrite.exe to alternate machine running Windows 8.1 Pro or Windows 10 and executable fails during startup with exception "Device cannot be identified." Specifically, in the 8.1 Pro machine, EControllerError in module SimpleHidWrite.exe at 000CBA49 Device cannot be identified. Getting the same problem with my USB/HID code which works in 8.1 but not others. Attempting to trace leads to the idea that the problem is thread related. Compiled file attached. | ||||
| Tags | No tags attached. | ||||
|
2017-03-07 00:26
|
SimpleHIDWrite.exe (1,241,088 bytes) |
|
|
Please use the latest GIT content, many changes have occurred in this area |
|
|
Thank you. I downloaded the most recent source (JVCL3-Source-2017-03-25). Since the problem appears in the USB/HID application, I checked hid.pas, hidtoken.pas and hidusage.pas against the 3.49 release using WinMerge. It reports all the new files are identical to their older versions. Could it have been fixed somewhere else? Dave |
|
|
I found this info when looking at a separate issue, perhaps it will help someone smarter than me find the problem with the JvHidDeviceController component code. "FPC [or other language] currently uses 32 bits (4 bytes) for integers, whether the machine is a 32-bit or 64-bit machine. This will cause code expecting an integer and a pointer to be the same size to fail as a 64bit machine uses 64-bit pointers." |
|
|
Could you check if the issue is still present in the latest GIT content? If yes, please provide the zipped sources of an application showing this. |
|
|
Is this the same as this one? http://issuetracker.delphi-jedi.org/view.php?id=6664 |
|
|
About this one: "FPC [or other language] currently uses 32 bits (4 bytes) for integers, whether the machine is a 32-bit or 64-bit machine. This will cause code expecting an integer and a pointer to be the same size to fail as a 64bit machine uses 64-bit pointers." Does FPC have NativeInt or NativePtr datatypes? If yes that might be a solution to this issue at least for newer Delphi versions. |
|
|
Yes, FPC has NativeInt And considering compatibility with older versions, the JvJCLUtils declares NativeInt properly for compiler versions where it is missing/bogus |
|
|
So do you propose to switch the code of JvHidDeviceController to NativeInt or NativePtr where applicable? |
|
|
I strongly believe that this has nothing to do with the issue at hand. The 32/64 pointer size is only valid if the application itself is 64bits. If the same application works on a computer, and not on another one, 32 versus 64 is definitely not an issue but rather an issue with drivers or windows version. Now, if inside JvHidDeviceController there is code that casts pointers (or handles) to Cardinal/LongInt/Integer, then this is an issue that needs to be fixed by using a NativeInt cast instead. |
|
|
I had a short look at this unit now and didn't spot any suspicious casts. So the issue seems to really originate from somewhere else. |
|
|
As asked before, could you please provide the zipped sources of a sample application showing this? |
|
|
I'm still seeing this problem (exception "Device cannot be identified") with what I think is the latest version JVCL (3.50?). It appears that the constructor "constructor TJvHidDevice.CtlCreate(const APnPInfo: TJvHidPnPInfo; const Controller: TJvHidDeviceController);" checks for all USB (HID) devices and throws the exception as soon as a device is checked that fails "if not HidD_GetAttributes(HidFileHandle, FAttributes) then raise EControllerError.CreateRes(@RsEDeviceCannotBeIdentified);" in the constructor body, even though the USB HID device of interest is working properly and as a consequence the code never gets to initialize this device. In other words this happens if a certain (external or internal) USB device is present that somehow doesn't comply or responds differently, even if that device is not used in the code. My fix for this is to replace the if-statement with "HidD_GetAttributes(HidFileHandle, FAttributes);" only. This works fine for me. Perhaps there is a cleaner way to handle USB devices at this point, but I don't know what the issue is with the device that is throwing the exception. I have limited knowledge on how to properly modify a component in installed JVCL. I did manage to do that in my case (Delphi 10.2), but perhaps someone can provide proper instructions as long as there is no permanent fix in JVCL. |
|
|
Do you know how to use git? If yes, you could create a GitHub account if you haven't got one yet, create a fork of JVCL, apply your fix and create a pull request. That's the usual way to get your fix in JVCL. |
|
|
I can confirm this behavior. I am using Rad Studio 11 and the latest JEDI from GetIt. (Though I have observed this on 10.4.x also and its GetIt pull). Of the 3 computers I have tested on, Only one computer, an HP Elitebook 850 G5, does this. The HID device that hangs is "HID Sensor Collection V2" (VID 8087 PID 0AC2). I am testing with the BasicDemo from the examples directory. I have discovered that if I disable the HID device or apply the HID compliant driver, the BasicDemo will execute properly. Also I have a HID exerciser that I got from Microchip's website years ago while working on PIC USB HID implementations. It works all the time, but has an error message at the top that says, "if your device is not present, then it fails HidD_GetAttributes", which is exactly where this is failing. It seems that the error handling for this type of HID device is not robust enough and a failed HidD_GetAttributes call is causing the whole program to fail. Have not thought about how to fix this, but will probably try b2's solution so I can continue to work. I am not a GitHub person, so even I do find a solution, not sure I can successfully add it to GitHub. NOTE; In Rad Studio 10.4.x, there was an RTL patch that came out. If you install JEDI without this patch, the HID controller will fail. I have confirmed this on one of the other computers. I originally thought that this somehow corrupted the 850 G5 laptop, but now I do not think this is true. I have tested on another computer and reinstalling JEDI after the RTL patch fixes the problem. |
|
|
While it is nice that you can confirm the behavior it would be nice if you could create a pull request for the provided fix, as that really increases the liklyhood of getting it into the distribution. Grab a Git client, create a fork, implement the fix and create a pull request. If you need help doing so let us know. |
|
|
I am not sure ignoring the failed DLL call is the right long term solution. But I also dont know what a good solution looks like, yet. I dont completely understand what the code is doing at the failure point and why the original author chose that implementation. Right now I am in the midst of trying to get a bigger project working. I have to come back to this, just dont know when. |
|
|
I dont believe there is an error in the code, it works as designed. What is missing is the OnDeviceCreateError handler. I have never seen documentaton that this be implemented. But after tracing through the code, the absence of this handler is causing the code to fail out completely, since the error is not handled. Below is what appears to be the minimum required. So far it is working on two projects. Depending on what is failing, you may need more error processing. My only issue is that in development you will continue to receive the error message that started this. The error message appears when you start the project and close the project. So maybe there is some improvement that can still be done. But for me right now, this has dropped far down on my list of things to do. procedure TformXXX.JvHidCtrlDeviceCreateError(Controller: TJvHidDeviceController; PnPInfo: TJvHidPnPInfo; var Handled, RetryCreate: Boolean); begin Handled:= TRUE; RetryCreate:= FALSE; FreeAndNil(PnPInfo); end; |
|
|
Are you able to create a pull request for your idea? If yes, can you do this please as otherwise it might never find its way into the code base. |
|
|
I believe there is no need for a pull request, maker54 is merely indicating that using the OnDeviceCreateError handler to "ignore" the exception allows to get a complete enumeration. This error handler was introduced during the developments for Issue 0005894 that I have now linked to this issue. |
|
|
A pull request is not warranted. This is a component/app implementation issue. On some Windows computers with unique HID devices, the app must implement the OnDeviceCreateError handler in order to enumerate the HID devices. With that said, the design mode issue is an annoyance, but not uncommon. I have very little experience with components in design mode and not even sure where to start to fix this. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-03-07 00:26 | davedelage | New Issue | |
| 2017-03-07 00:26 | davedelage | File Added: SimpleHIDWrite.exe | |
| 2017-03-24 17:37 | obones | Note Added: 0021414 | |
| 2017-03-24 17:37 | obones | Status | new => feedback |
| 2017-03-25 20:01 | davedelage | Note Added: 0021416 | |
| 2017-04-18 18:41 | davedelage | Note Added: 0021423 | |
| 2018-07-18 15:53 | obones | Note Added: 0021522 | |
| 2019-03-07 21:32 | mh | Note Added: 0021622 | |
| 2019-03-19 20:02 | mh | Note Added: 0021652 | |
| 2019-03-20 09:02 | obones | Note Added: 0021653 | |
| 2019-04-25 21:25 | mh | Note Added: 0021737 | |
| 2019-04-26 09:51 | obones | Note Added: 0021745 | |
| 2019-04-27 13:26 | mh | Note Added: 0021755 | |
| 2020-05-19 10:16 | obones | Note Added: 0021917 | |
| 2021-09-02 17:27 | b2 | Note Added: 0021991 | |
| 2021-09-04 14:12 | mh | Note Added: 0021992 | |
| 2021-09-23 00:55 | maker54 | Note Added: 0022005 | |
| 2021-09-23 19:45 | mh | Note Added: 0022006 | |
| 2021-09-23 22:39 | maker54 | Note Added: 0022007 | |
| 2021-10-08 23:45 | maker54 | Note Added: 0022008 | |
| 2021-10-09 17:24 | mh | Note Added: 0022009 | |
| 2021-10-09 17:32 | obones | Relationship added | related to 0005894 |
| 2021-10-09 17:34 | obones | Note Added: 0022010 | |
| 2021-10-09 19:39 | maker54 | Note Added: 0022011 |
