Skip to content
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

New handy tech display models #9691

Merged

Conversation

@FelixGruetzmacher
Copy link
Contributor

commented Jun 7, 2019

Link to issue number:

Does not apply.

Summary of the issue:

When vendor-specific applications need direct access to a Handy Tech Braille display, they indicate this by sending a window message to a driver-created invisible window. Up until now, the native NVDA driver for Handy Tech devices does not create this window.

Description of how this pull request fixes the issue:

The driver now creates the window upon instantiation. It also responds to the sleep and wake messages appropriately.

Testing performed:

Tested with Actilino by sending a file to it via HTCom while driver was running. File was successfully sent, and afterwards the driver resumed its operation normally, i.e. the device restarted to braille.

Known issues with pull request:

None known.

Change log entry:

Section: Bug fixes

  • HTCom can now be used with a Handy Tech Braille display in combination with NVDA.
    Section: New features
  • The Handy Tech Basic Braille Plus family of displays is now natively supported by NVDA.

FelixGruetzmacher and others added some commits Feb 7, 2019

Added support for the Basic Braille Plus family of displays. Added sl…
…eep mode functionality so that applications can signal to the driver that it temporarily close its ports.

@leonardder leonardder requested review from leonardder and michaelDCurran Jun 7, 2019

@FelixGruetzmacher

This comment has been minimized.

Copy link
Contributor Author

commented Jun 8, 2019

Unfortunately I found an issue after opening this. Currently, when the driver is instantiated, it creates a hidden window to take messages from our proprietary apps, and when the driver is terminated or its constructor fails, that window is destroyed. However, I failed to take into account that instantiation of the driver may take place in a thread which is not in a position to handle window messages, and which is also different from the thread which will eventually attempt to destroy the window. In this scenario, which happens for automatic detection, we'll be left with a message window that not only won't handle messages but also won't go away when asked. And in fact this is what I'm seeing.
Would it be acceptable to create the hidden window at module level rather than as part of a driver instance? It would mean that window would exist for every running NVDA on every system as driver modules are always imported. Strictly speaking I don't like such artifacts but right now I can see no other simple workaround. Could I get away with it?

@leonardder

This comment has been minimized.

Copy link
Collaborator

commented Jun 8, 2019

@FelixGruetzmacher

This comment has been minimized.

Copy link
Contributor Author

commented Jun 8, 2019

@leonardder thanks, that helped a lot. The problem went away for me, and I committed the change.

@leonardder

This comment has been minimized.

Copy link
Collaborator

commented Jun 8, 2019

@FelixGruetzmacher

This comment has been minimized.

Copy link
Contributor Author

commented Jun 8, 2019

@leonardder

This comment has been minimized.

Copy link
Collaborator

commented Jun 8, 2019

@FelixGruetzmacher

This comment has been minimized.

Copy link
Contributor Author

commented Jun 8, 2019

@bramd

This comment has been minimized.

Copy link
Contributor

commented Jun 8, 2019

@FelixGruetzmacher I think NVDA stores just LF line endings in Git, since Git converts CRLF by default to LF on commit. This can be controlled in Gits config, see https://stackoverflow.com/questions/10418975/how-to-change-line-ending-settings for example.

@FelixGruetzmacher

This comment has been minimized.

Copy link
Contributor Author

commented Jun 8, 2019

className = u"Handy_Tech_Server"
def __init__(self, driver):
super(InvisibleDriverWindow, self).__init__(u"Handy Tech Server")
self.driver = driver

This comment has been minimized.

Copy link
@leonardder

leonardder Jun 10, 2019

Collaborator

Please make this a weak reference. You can see how this works on the Model class.

There is also a possibility to provide a callback to the reference that is called when the reference dies, i.e. when the driver instance dies. We really need to make sure that the window is destroyed in that case. Could you also test this, e.g. by forcefully disconnecting a device and checking whether the window is destroyed correctly? I assume it will if terminate is called when the driver loses its connection.

self.driver = driver
def windowProc(self, hwnd, msg, wParam, lParam):
if msg == window_message:
if wParam == 100 and lParam == 1:

This comment has been minimized.

Copy link
@leonardder

leonardder Jun 10, 2019

Collaborator

Were do 100 and 1 stand for? Could you make these constants? Note that constants are capitalised.

self.driver.go_to_sleep()
elif wParam == 100 and lParam == 0:
self.driver.wake_up()
return 0

This comment has been minimized.

Copy link
@leonardder

leonardder Jun 10, 2019

Collaborator

What does 0 mean in this context?

self.driver.wake_up()
return 0

window_message=windll.user32.RegisterWindowMessageW(u"Handy_Tech_Server")

This comment has been minimized.

Copy link
@leonardder

leonardder Jun 10, 2019

Collaborator

This is now global to the driver module and therefore to NVDA as a whole. It would be nice if we could avoid this by registering the window message in create_message_window and unregister it in self.destroy_message_window

try:
self._messageWindow.destroy()
except:
log.debugWarning("", exc_info=True)

This comment has been minimized.

Copy link
@leonardder

leonardder Jun 10, 2019

Collaborator

Make sure that if you move window message registering to the driver, that it is properly unregistered.

@feerrenrut feerrenrut self-requested a review Jun 11, 2019

@leonardder
Copy link
Collaborator

left a comment

Almost there. Thanks for the great work until now.

time.sleep(self.timeout)
self._dev.close()
self._dev = None
time.sleep(self.timeout) #

This comment has been minimized.

Copy link
@leonardder

leonardder Jun 11, 2019

Collaborator

There's an unnecessary hash after this line.

@FelixGruetzmacher

This comment has been minimized.

Copy link
Contributor Author

commented Jun 11, 2019

@leonardder
Copy link
Collaborator

left a comment

I'm sorry, I missed these imports, see below.

@@ -9,6 +9,7 @@
Braille display driver for Handy Tech braille displays.
"""

import ui

This comment has been minimized.

Copy link
@leonardder

leonardder Jun 11, 2019

Collaborator

This now seems duplicated

@leonardder

This comment has been minimized.

Copy link
Collaborator

commented Jun 17, 2019

@michaelDCurran is there any way we could have this in 2019.2?

@michaelDCurran

This comment has been minimized.

Copy link
Contributor

commented Jun 17, 2019

@zstanecic

This comment has been minimized.

Copy link
Contributor

commented Jun 17, 2019

@zstanecic

This comment has been minimized.

Copy link
Contributor

commented Jun 17, 2019

@FelixGruetzmacher

This comment has been minimized.

Copy link
Contributor Author

commented Jun 17, 2019

@zstanecic

This comment has been minimized.

Copy link
Contributor

commented Jun 17, 2019

@josephsl

This comment has been minimized.

Copy link
Collaborator

commented Jun 17, 2019

@FelixGruetzmacher

This comment has been minimized.

Copy link
Contributor Author

commented Jun 17, 2019

@josephsl

This comment has been minimized.

Copy link
Collaborator

commented Jun 17, 2019

@zstanecic

This comment has been minimized.

Copy link
Contributor

commented Jun 17, 2019

@FelixGruetzmacher

This comment has been minimized.

Copy link
Contributor Author

commented Jun 17, 2019

@josephsl

This comment has been minimized.

Copy link
Collaborator

commented Jun 17, 2019

@leonardder

This comment has been minimized.

Copy link
Collaborator

commented Jun 17, 2019

An alternative could be stripping this pr back to the pure basics, i.e. adding support for basic braille plus, not for the window message handling. Then, we could do the window message handling in a new pr for 2019.3

@FelixGruetzmacher

This comment has been minimized.

Copy link
Contributor Author

commented Jun 17, 2019

@zstanecic

This comment has been minimized.

Copy link
Contributor

commented Jun 17, 2019

@michaelDCurran

This comment has been minimized.

Copy link
Contributor

commented Jun 21, 2019

Since another bug was identified in the beta which means we need to now release a beta2, I am going to review this, and if I approve it I will merge it to beta.

@michaelDCurran michaelDCurran merged commit f8507be into nvaccess:beta Jun 21, 2019

1 check passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details

@nvaccessAuto nvaccessAuto added this to the 2019.3 milestone Jun 21, 2019

@michaelDCurran michaelDCurran modified the milestones: 2019.3, 2019.2 Jun 21, 2019

@michaelDCurran

This comment has been minimized.

Copy link
Contributor

commented Jun 25, 2019

Beta2 (containing this pr) has been published. Can you please test the beta and confirm the changes in this pr are functioning correctly in the beta?
2019.2Beta2 download: https://ci.appveyor.com/api/buildjobs/4kuwrvn7r0l2erd1/artifacts/output/nvda_2019.2beta2.exe
If everything is okay, then I will release rc1 within the next few days.

@FelixGruetzmacher

This comment has been minimized.

Copy link
Contributor Author

commented Jun 25, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.