Try to use window.edit.Edit when an editable window supports it by LeonarddeR · Pull Request #8165 · nvaccess/nvda

LeonarddeR · 2018-04-11T18:33:29Z

Link to issue number:

Closes #8102
Closes #636

Summary of the issue:

NVDA uses the display model for editable text cases where there is a caret in the window and there doesn't seem to be another overlay class that implements editing. However, NVDA is a bit conservative in this, only using window.edit.Edit for objects with a particular window class or for windowless richEdit.

Description of how this pull request fixes the issue:

When finding an overlay class for an object and there is a caret in the window, rather than directly choosing DisplayModelEditableText, this pr will send the EM_LINELENGTH message to the window. This window message always returns 1 or higher for windows that support the edit API, also for single line edit controls. This means that, when the window responds with >=1 to EM_LINELENGTH, the edit API is supported. In this case, a new UnidentifiedEdit class is used that makes no assumptions about the edit API version. For these controls, this pr will try to construct an ITextDocumentTextInfo object to retrieve text information. If that fails, the implementation will fall back to EditTextInfo.

Testing performed:

Tested the notetab text editor. Instead of using DisplayModelEditableText for the edit control, UnidentifiedEdit is now used, and the control even implements ITextDocument support. Also tested a corporate Delphi application that has edit controls with custom window classes.

Known issues with pull request:

None

Change log entry:

Bug fixes
- In some text controls, particularly in Delphi applications, the information provided about editing and navigating is now much more reliable. (NVDA doesn't speak with NOTETAB text editor #636, Use NVDAObjects.window.edit.Edit overlay class for editable windows with window text #8102)

…rts it regardless of window class. Also, try ITextDocument in more cases and remove old pre Windows Vista code Inherrit from RichEdit

michaelDCurran

This pr is rather hard to follow due to the large amount of constants moved to winUser. I understand why you did it, but there are various bits of code here which I'm confused as to why they are removed.

michaelDCurran · 2018-04-16T05:02:24Z

 				pDoc=None
 			if pDoc:
 				self._ITextDocumentObject=pDoc
-				self.useITextDocumentSupport=True


Why was this removed?

I will explain this below.

michaelDCurran · 2018-04-16T05:08:12Z

 				start=end
 				end=watchdog.cancellableSendMessage(self.obj.windowHandle,EM_FINDWORDBREAK,WB_MOVEWORDRIGHT,offset)
 			return (start,end)
-		elif winVersion.winVersion.major<6: #Implementation of standard edit field wordbreak behaviour (only breaks on space)


Why is all this code removed?

Because it is code that would only apply to Windows XP.

LeonarddeR · 2018-04-16T12:08:47Z

 	editAPIVersion=0
-	editAPIUnicode=True
-	# #4291: Use ITextDocument in Windows 7 and later, as it's very slow in earlier versions.
-	useITextDocumentSupport=(winVersion.winVersion.major,winVersion.winVersion.minor)>=(6,1)


@michaelDCurran: the useITextDocumentSupport property seems to have been there to limit the support of ITextDocument to windows 7 and abbove. Since we aren't longer supporting Windows versions older than 7, this code now became obsolete (i.e. this variable would be always True). That's also the reason why I removed it from the IAccessible windowless rich text edit support as you saw.

Qchristensen · 2018-04-17T03:25:17Z

One issue I've found from this PR, is moving the mouse while Notepad is open causes a lovely staccato of the error sound. The error it's generating is:

ERROR - eventHandler.executeEvent (13:00:27.961):
error executing event: mouseMove on <NVDAObjects.Dynamic_IAccessibleEditWindowNVDAObject object at 0x04F52B50> with extra args of {'y': 314, 'x': 953}
Traceback (most recent call last):
File "eventHandler.pyc", line 152, in executeEvent
File "eventHandler.pyc", line 92, in init
File "eventHandler.pyc", line 100, in next
File "NVDAObjects_init_.pyc", line 923, in event_mouseMove
File "documentBase.pyc", line 24, in makeTextInfo
File "textInfos\offsets.pyc", line 282, in init
File "NVDAObjects\window\edit.pyc", line 196, in _getOffsetFromPoint
NameError: global name 'EM_CHARFROMPOS' is not defined

… reflected

Incubates #8165.

LeonarddeR · 2018-04-17T11:10:45Z

@Qchristensen commented on 17 Apr 2018, 05:25 CEST:

One issue I've found from this PR, is moving the mouse while Notepad is open causes a lovely staccato of the error sound.

Fixed in ebfe710 .

Qchristensen · 2018-04-17T11:33:22Z

That's behaving better, thanks Leonard!

beqabeqa473 · 2018-05-03T06:41:02Z

hello.

maybe after this pull request i get this
ImportError: cannot import name EM_SETSEL

i wrote spell checker addon which gets and sets selection.
after some update i am getting this error and addon no longer works.
is it by design or it is a miss?

thanks.

michaelDCurran · 2018-05-03T07:04:57Z

Those constants moved from NVDAObjects.window.edit to winUser.

LeonarddeR · 2018-05-03T07:58:43Z

@michaelDCurran commented on 3 mei 2018 09:04 CEST:

Those constants moved from NVDAObjects.window.edit to winUser.

I guess we could revert this change, but as Window.windowTextLineCount relies on one of these constants, the edit module didn't seem to be the right place for it. Add to that the fact that these constants live in winUser.h in the windows SDK.

beqabeqa473 · 2018-05-03T08:22:45Z

aah, ok, i will change that in addon itself. thanks.

…

On 5/3/18, Leonard de Ruijter ***@***.***> wrote: ***@***.*****](https://github.com/michaelDCurran) commented on [3 mei 2018 09:04 CEST](#8165 (comment) "2018-05-03T07:04:57Z - Replied by Github Reply Comments"): > Those constants moved from NVDAObjects.window.edit to winUser. I guess we could revert this change, but as Window.windowTextLineCount not relies on one of these constants, the edit module didn't seem to be the right place for it. Add to that the fact that these constants live in winUser.h in the windows SDK. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #8165 (comment)

-- with best regards beqa

@jcsteh

Fixes #8996 In #8165 we started using Unidentifiededit for editable text fields in which there is a caret and which seems to support Edit API. While both of these criterion's are true for Fast Log Entry edit fields their WindowText contains complete garbage and UnidentifiedEdit relies on Windowtext being correct. Instead: 1. For edit field in Fast Log Entry DisplayModelEditableText is used similar to the pre #8165 2. DisplayModelEditableText no longer inherits from EditableText rather from EditableTextWithoutAutoSelectDetection which makes selection announced when the color used for highlight in a particular app is the default Windows highlight color - This has been suggested by @jcsteh in #4535

@jcsteh

…s#11488) Fixes nvaccess#8996 In nvaccess#8165 we started using Unidentifiededit for editable text fields in which there is a caret and which seems to support Edit API. While both of these criterion's are true for Fast Log Entry edit fields their WindowText contains complete garbage and UnidentifiedEdit relies on Windowtext being correct. Instead: 1. For edit field in Fast Log Entry DisplayModelEditableText is used similar to the pre nvaccess#8165 2. DisplayModelEditableText no longer inherits from EditableText rather from EditableTextWithoutAutoSelectDetection which makes selection announced when the color used for highlight in a particular app is the default Windows highlight color - This has been suggested by @jcsteh in nvaccess#4535

Fix-up of nvaccess#8165

* Don't use UnidentifiedEdit for windows with empty windowText Fix-up of #8165 * Update what's new Co-authored-by: Michael Curran <mick@nvaccess.org>

Try to use NVDAObjects.window.edit.Edit when an editable window suppo…

284206a

…rts it regardless of window class. Also, try ITextDocument in more cases and remove old pre Windows Vista code Inherrit from RichEdit

michaelDCurran reviewed Apr 16, 2018

View reviewed changes

LeonarddeR commented Apr 16, 2018

View reviewed changes

michaelDCurran approved these changes Apr 16, 2018

View reviewed changes

michaelDCurran added a commit that referenced this pull request Apr 16, 2018

Incubates #8165

27f1150

nvaccessAuto added the incubating label Apr 16, 2018

nvaccessAuto assigned michaelDCurran Apr 16, 2018

Fixed one case where the movement of EM_CHARFROMPOS to winUser wasn't…

ebfe710

… reflected

LeonarddeR pushed a commit that referenced this pull request Apr 17, 2018

Merge branch 'editControls' into next

26daa5c

Incubates #8165.

nvaccessAuto assigned LeonarddeR and unassigned michaelDCurran Apr 17, 2018

michaelDCurran merged commit 874948c into nvaccess:master May 8, 2018

nvaccessAuto removed the incubating label May 8, 2018

nvaccessAuto added this to the 2018.2 milestone May 8, 2018

lukaszgo1 mentioned this pull request Dec 13, 2018

Fix regression when reading and deleting text in MS Excel edit fields. #9063

Merged

LeonarddeR added the BabbageWork Pull requests filed on behalf of Babbage B.V. label Oct 11, 2019

lukaszgo1 mentioned this pull request Aug 12, 2020

Stop using UnidentifiedEdit in Fast Log Entry edit field #11488

Merged

lukaszgo1 added a commit to lukaszgo1/nvda that referenced this pull request Dec 22, 2020

Don't use UnidentifiedEdit for windows with empty windowText

dad0478

Fix-up of nvaccess#8165

lukaszgo1 mentioned this pull request Dec 22, 2020

Don't use UnidentifiedEdit for windows with empty windowText #11966

Merged

Uh oh!

Conversation

LeonarddeR commented Apr 11, 2018

Link to issue number:

Summary of the issue:

Description of how this pull request fixes the issue:

Testing performed:

Known issues with pull request:

Change log entry:

Uh oh!

michaelDCurran left a comment

Choose a reason for hiding this comment

Uh oh!

michaelDCurran Apr 16, 2018

Choose a reason for hiding this comment

Uh oh!

LeonarddeR Apr 16, 2018

Choose a reason for hiding this comment

Uh oh!

michaelDCurran Apr 16, 2018

Choose a reason for hiding this comment

Uh oh!

LeonarddeR Apr 16, 2018

Choose a reason for hiding this comment

Uh oh!

LeonarddeR Apr 16, 2018

Choose a reason for hiding this comment

Uh oh!

Qchristensen commented Apr 17, 2018

Uh oh!

LeonarddeR commented Apr 17, 2018

Uh oh!

Qchristensen commented Apr 17, 2018

Uh oh!

beqabeqa473 commented May 3, 2018

Uh oh!

michaelDCurran commented May 3, 2018 via email

Uh oh!

LeonarddeR commented May 3, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

beqabeqa473 commented May 3, 2018 via email

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

LeonarddeR commented May 3, 2018 •

edited

Loading