New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Handy Tech displays using USB HID without requiring driver installation #854
Comments
Comment 1 by jteh on 2010-08-24 01:10 |
Comment 2 by bramd on 2010-12-19 18:20 |
Comment 3 by jteh (in reply to comment 2) on 2010-12-20 01:40
Haven't tried yet myself. However, my research suggests that a manifest can be loaded at runtime using activation contexts. See Activation Context Reference in MSDN for details. I think the steps would be something like this:
|
Comment 4 by jteh on 2011-01-14 07:56 In any case, it looks like the only solution is to embed this in our application manifest. We can't just override our manifest statically, as we need the UAC info to be dynamically configurable. From memory, this will require us to tweak py2exe somewhat, as I don't think it allows arbitrary chunks to be included in the manifest. |
Comment 5 by jteh (in reply to comment 4) on 2011-01-19 07:44
I've figured out how to do this. I've tested it and it does work. We need to make sure the dll doesn't get loaded unless it is actually needed and a few other details. |
Comment 6 by jteh on 2011-01-19 07:53 |
Comment 7 by jteh on 2011-01-20 02:59 |
Reported by jteh on 2010-08-24 01:08
Some Handy Tech displays now implement the USB HID device class, which means that they don't require USB drivers to be installed. However, NVDA currently requires the Handy Tech COM server to be installed on the system, which breaks the portability afforded by the use of HID. NVDA should bundle the COM server so that these displays can be used without any installation.
Because it is a COM server, it needs to be registered with the system. This can be done using application manifests. I'd prefer to avoid modifying NVDA's manifest if possible. An option that needs to be explored is to use activation contexts to register a manifest at runtime. Failing this, we do want the feature, so modifying our application manifest is acceptable if it is the only way.
The text was updated successfully, but these errors were encountered: