View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0006652JEDI VCL00 JVCL Componentspublic2018-10-08 10:442020-05-19 10:19
ReporterGeroldAssigned Toobones 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionno change required 
Product VersionDaily / GIT 
Target VersionFixed in Version 
Summary0006652: JvHidDeviceController LoadSetupApi returns false
DescriptionHi

I have a program for a HID device using TJvHidDeviceController and the program works on most PC's but not on some machines. It turns out, that on these machines these two functions
- SetupDiInstallDeviceInterfaces
- SetupDiRegisterCoDeviceInstallers
are not available.

That means, that LoadSetupApi in JvSetupApi.pas is returning false.

These functions are not used in JvHidControllerClass.pas.

Only these 5 functions are required:
- SetupDiGetDeviceRegistryProperty
- SetupDiGetClassDevs
- SetupDiEnumDeviceInterfaces
- SetupDiGetDeviceInterfaceDetail
- SetupDiDestroyDeviceInfoList

In LoadSetupApi, more than 400 functions are dynamically linked (if case SETUPAPI_LINKONREQUEST is set) and if one fails, than the function returns FALSE.

I am wondering, if it is a good idea to use LoadSetupApi in TJvHidDeviceController. Why not write another function which is linking just the above functions?

Also, would it not be wise to have an overloaded function

function GetModuleSymbolEx(Module: TModuleHandle; SymbolName: string; var ErrorMsg: string): Pointer;

which returns in ErrorMsg the FIRST SymbolName where GetProcAddress failed?

In this case, LoadSetupApi could return, which of the more than 400 linked functions failed.

TagsNo tags attached.

Activities

mh

2019-04-25 20:43

reporter   ~0021734

Issued pull request for a version which inplements a LoadAPI sort of function inside JvHIDControllerClass unit:

https://github.com/project-jedi/jvcl/pull/89

Please check it.

obones

2019-04-30 15:31

administrator   ~0021777

I don't like duplication of code, I'd rather have JvSetupApi modified to be able to tell it which of the 400 functions are to be loaded.

But I even think that there should not be any reason to change that because the MSDN documentation says that the two "missing" functions are available since Windows 2000.

So the real question is "On what version of Windows was this a problem?"

mh

2019-04-30 21:41

reporter   ~0021780

I can agree with the not liking of duplication of code. But I wonder why those two methods mentioned are not available on some machines even if they should be available since Windows 2000, an OS no longer supported by Microsoft since 2006.

Question to the original creator of this issue here: which OS do those machines where it fails run?

Gerold

2019-05-01 07:21

reporter   ~0021782

I received an answer from one person using my program (which uses TJvHidDeviceController) and he said, that he is using Linux and CrossOver. I did not know this. Maybe the other person is using Linux too with CrossOver (or Wine).

At the moment, my program is working on these machines, cause I created a new unit based on the JvHidController.pas and importing just these functions:

  SetupDiGetDeviceRegistryPropertyA: TSetupDiGetDeviceRegistryPropertyA;
  SetupDiGetDeviceRegistryPropertyW: TSetupDiGetDeviceRegistryPropertyW;
  SetupDiGetDeviceRegistryProperty: TSetupDiGetDeviceRegistryProperty;
  SetupDiGetClassDevsA: TSetupDiGetClassDevsA;
  SetupDiGetClassDevsW: TSetupDiGetClassDevsW;
  SetupDiGetClassDevs: TSetupDiGetClassDevs;
  SetupDiEnumDeviceInterfaces: TSetupDiEnumDeviceInterfaces;
  SetupDiGetDeviceInterfaceDetailA: TSetupDiGetDeviceInterfaceDetailA;
  SetupDiGetDeviceInterfaceDetailW: TSetupDiGetDeviceInterfaceDetailW;
  SetupDiGetDeviceInterfaceDetail: TSetupDiGetDeviceInterfaceDetail;
  SetupDiDestroyDeviceInfoList: TSetupDiDestroyDeviceInfoList;

In fact, almost like the modified JvHidControllerClass unit from above, but I do import 11 functions, not 10.

Anyway, I would like to have an idea, why "LoadSetupApi" returned false.

PS:
I just noticed, that the latest JVCL Daily packages are from 2019-04-30 08:32:24 UTC, but the latest JCL Daily packages are from 2018-04-29 06:27:35 UTC. Is this a bug and for the JCL it should be 2019 and not 2018 or is the JCL realy not updated since more than a year?

Or is my link old?
http://jcl.sourceforge.net/daily/

obones

2020-05-19 10:19

administrator   ~0021920

LoadSetupAPI returns false because the entry point is missing.

As to the daily zips, their generation has been fixed a few weeks back

Issue History

Date Modified Username Field Change
2018-10-08 10:44 Gerold New Issue
2019-04-25 20:43 mh Note Added: 0021734
2019-04-30 15:31 obones Note Added: 0021777
2019-04-30 15:31 obones Status new => feedback
2019-04-30 21:41 mh Note Added: 0021780
2019-05-01 07:21 Gerold Note Added: 0021782
2020-05-19 10:19 obones Assigned To => obones
2020-05-19 10:19 obones Status feedback => resolved
2020-05-19 10:19 obones Resolution open => no change required
2020-05-19 10:19 obones Note Added: 0021920