After updating to version 22.1.4, some code behaviors are inconsistent with before.

Hello,

There were some word selection updates made in v22.1.3.  I see in TextSnapshot.GetWordTextRange where the exception could occur if you call it with an offset < 0.  Technically that offset is out of range from the snapshot so the exception is correct.  May I ask why you calling it with a negative value?

For the other question, I don't believe there were any changes made to the LL(*) Parser Framework.  Are you editing with one of our add-on languages or are you editing with a custom syntax language that uses the grammar?

It is recommended to adopt a smoother upgrade method.

Some of our modules are currently developed and in certain versions it works fine. But some internal issues that the current upgrade fixes, we had to go back and fix those.Or you can only postpone the version upgrade.

Have you ever considered dealing with this kind of problem, marking the method as obsolete, and then handling this kind of exception in the new version, will it make the upgrade process smoother?

Hello,

I'm sorry that the change caused issues for you.  We always try to only make any breaking changes in major version updates.  In this case, a negative offset was always intended to be invalid input, and we didn't identify the logic changes made as triggering a breaking change.

Thanks for your explanation.But I still want to mention that for us control users, the behavior changes of some basic interfaces may have a much greater impact than imagined.

In the process of product development to release, we will go through many testing stages. So the final version is stable, although some of its code may have errors, such as getting the current position word offset as plural, but they pass the test in this specific version.

After upgrading the control version, you may fix these problems before. There is no logical error, but the behavior of the interface has changed. So some problems with our previous release phase testing will be exposed.

I don't mean that it is wrong to do this, but that there will be a large number of calls to this type of basic interface, and we may not be able to upgrade it in the short term. And possibly a full test. But some bug fixes in the new version are problems we have to solve. Therefore, our expectation is that for changes in the behavior of this type of basic interface (including the previous wrong behavior is now correct), we should adopt a smoother adjustment, keep the old interface, mark it as expired, and provide a suggested new interface , let users decide when to upgrade and test it. Will this be better? Of course, this is just my personal suggestion, and more needs to be heard from you.

We appreciate you sharing your concerns about the change, and truly regret the hardship that it caused. Your feedback will certainly influence how we address future changes and we have already discussed making sure that new argument validation checks are only added with major releases. API overloading and marking older API's as obsolete is certainly an option to consider based on the situation.

After further confirmation, we found a new problem with editor.ActiveView.CurrentSnapshot.GetWordText(offset).

Example code:

Console|.

The offset of the above code cursor is 7。

In version 22.1.2 the result returned by this method is '.' 

But in version 22.1.4 it returns 'Console'

This update appears to be a duplicate of one reported by a colleague. Please refer to the other post for follow-up.