Fix getting offsets from points in edit controls when offset numbers exceed 16 bits #8397
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.
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: