Fix TextInfo.moveToCodepointOffset() in PoEdit

[mltony]

Link to issue number:

N/A

Summary of the issue:

TextInfo.moveToCodepointOffset() somtimes raises exception in PoEdit:

RuntimeError: Inner textInfo text ' lock' doesn't match outer textInfo text 'Toggle input lock

Description of user facing changes

N/A

Description of development approach

This is caused by a bug (or peculiarity) of TextInfo implementation in PoEdit. It is using ITextDocumentTextInfo and when calling .collapse(True) in some cases it actually doesn't collapse to the very end. This seems to be happening when there is only a single line in the text box and when you expand to paragraph, it reports newline being the last character of that paragraph, however when collapsing to the end, it places textInfo right before that last newline character. This breaks my assumption that collapse(True) always collapses to the end.
In order to work around this peculiarity I created TextInfo.getTextInfoForCodepointMovement() method, which just returns a copy of current textInfo, except for overloaded implementation in ITextDocumentTextInfo, where it checks for collapse peculiarity, and, if detected, then trims that last fake newline character.

Testing strategy:

Tested manually in PoEdit.

Known issues with pull request:

N/A

Code Review Checklist:

• Documentation:
  • Change log entry
  • User Documentation
  • Developer / Technical Documentation
  • Context sensitive help for GUI changes
• Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English
• API is compatible with existing add-ons.
• Security precautions taken.

[LeonarddeR]

This pull request now addresses a symptom, while in reality it should address the actual problem IMO.
Shouldn't this pr address the issue in collapse itself? I.e. rather than fixing this only for code point offset, I'd rather see the collapse method revised to address it.

[LeonarddeR]

@michaelDCurran The current implementation of ITextDocumentTextInfo has a manual implementation to collapse, while there is in fact a Collapse method on ITextRange. You wrote the collapse method fifteen years ago, so I'm inclined to say you don't remember why you implemented it the way you you did😉.
I think we should consider adapting collapse to execute self._rangeObj.Collapse(not end)

[michaelDCurran]

Certainly worth trying. No doubt on some implementation it either raised an error and or it inappropriately moved start offset. But yes, I really can't remember now. Message ID: ***@***.***>

[mltony]

Changing to ITextRange::collapse() won't help as it exhibits exactly the same problem:

>>> t=focus.makeTextInfo('caret')
>>> t.expand('paragraph')
>>> t._rangeObj.start, t._rangeObj.end
(0, 10)
>>> tt=t.copy()
>>> tt.collapse(False)
>>> tt._rangeObj.start, tt._rangeObj.end
(0, 0)
>>> tt=t.copy()
>>> tt.collapse(True)
>>> tt._rangeObj.start, tt._rangeObj.end
(9, 9)

[LeonarddeR]

I had another quick look. It seems that ITextRange.SetRange causes the off by one issue, i.e. it doesn't allow setting the range to exclusive offsets.
Note that when forcing UIA in PoEdit, this problem doesn't occur. This suggests that the UIA proxy either doesn't use ITextRange internally or properly accounts for this issue.
Could you try changing collapse to set self._rangeObj.Start and self._rangeObj.End directly? That's what setEndPoint does, so I guess that'll work here.

[mltony]

Nope:

>>> t=focus.makeTextInfo('caret')
>>> t.expand('paragraph')
>>> t._rangeObj.start, t._rangeObj.end
(0, 10)
>>> tt=t.copy()
>>> tt._rangeObj.start, tt._rangeObj.end
(0, 10)
>>> tt._rangeObj.start = 10
>>> tt._rangeObj.start, tt._rangeObj.end
(9, 9)

pending questions

[LeonarddeR]

O wow, this is very weird.
This is also reproducible in Wordpad by the way, so I think it is a global ITextRange thing. Another reason to use UIA for these controls, unfortunately we had to revert that.
I understand that it is pretty hard to get this right, but I still feel we need to fix this in the textInfo implementation rather than only for code point offset fetching. May be we should do that in a follow up, though.

[LeonarddeR]

This is also reproducible in Wordpad, so seems to be ITextRange related in general. Could you please update this comment accordingly?

[LeonarddeR]

I think this should be a private method:

Suggested change

	def getTextInfoForCodepointMovement(self) -> Self:
	def _getTextInfoForCodepointMovement(self) -> Self: