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

Fix getting offsets from points in edit controls when offset numbers exceed 16 bits #8397

merged 5 commits into from Jul 18, 2018


Copy link

@leonardder leonardder commented Jun 14, 2018

Link to issue number:


Summary of the issue:

When getting an offset from a point in edit controls, such as notepad, a 32 bit value is returned which contains the offset in the LOWORD and the line number in the HIWORD. UNtil now, NVDA was only using the LOWORD value, which caused issues when the associated offset was higher than 65535 or 0xFFFF.

Description of how this pull request fixes the issue:

When the length of the text control exceeds 0xffff, we can't simply return the LOWORD of the EM_CHARFROMPOS result, as that might be wrong. Instead, we get the start offset that is associated with the line number and calculate the real offset for the given point based on that start offset.

Testing performed:

Tested getOffsetFromPoint behavior in Notepad. I also tested Wordpad with the text info forced to EditTextInfo. That code shouldn't have been touched, and it indeed returned the correct result as well.

Furthermore, I covered the case where for example the line start offset would be <= 0xffff whereas the offset belonging to the point ought to be greater than 0xffff.

Change log entry:

  • Bug fixes
    • Mouse tracking is now much more accurate in Notepad and other plain text edit controls when in a document with more than 65535 characters. (#8397)
@leonardder leonardder requested a review from michaelDCurran Jun 14, 2018
@leonardder leonardder force-pushed the BabbageCom:editOffsetFromPoint branch from eb90ec7 to f83f193 Jun 14, 2018
lineStartLW = winUser.LOWORD(lineStart)
if lineStartLW > offset:
offset+= 0x10000

This comment has been minimized.


dkager Jun 15, 2018

Space after =

# Offsets are 16 bits, therefore for large documents, we need to make sure that the correct offset is returned.
# We can calculate this by using the line number.
lineStartLW = winUser.LOWORD(lineStart)

This comment has been minimized.


dkager Jun 15, 2018

What is contained in the LOWORD? Could the variable name make this clear?

Leonard de Ruijter
# Get the last 16 bits of the line number
if lineStart16 > offset:

This comment has been minimized.


michaelDCurran Jun 18, 2018

Can you better explain what these two lines do?

michaelDCurran added a commit that referenced this pull request Jun 18, 2018
@michaelDCurran michaelDCurran merged commit 0814aa7 into nvaccess:master Jul 18, 2018
1 check passed
1 check passed
continuous-integration/appveyor/pr AppVeyor build succeeded
@nvaccessAuto nvaccessAuto added this to the 2018.3 milestone Jul 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants