Exception with SyntaxEditor

Hi Kasper,

Hmm, this unfortunately is not something that we can really fix without being able to debug it via a sample. From looking at the stack trace though, I would think that you should be able to repro it reliably if you can narrow down the conditions that cause it.

It would seem from the stack trace that the display line collection is out of sync with the document's contents. So in your app, when it happens, pay attention to what selection you had in the SyntaxEditor at the time of switch and how far down were you scrolled. Also, look at the size of each Document. For instance is the one you're switching to, much smaller than the other.

If you can get that combination and then repro it reliably, you should be able to build a tiny sample project that will allow us to debug it and sort it out.

I have hit the same problem and can reproduce it reliably. Unfortunately this is in my main program which is not able to be shared. I've started creating a simplified example but at this stage the problem has not shown up. I suspect that this is because the simple example does not yet implement the same parsing and highlighting.

What I do know:

- The IndexOutOfRangeException occurs when changing which Document is assigned to the SyntaxEditor.
- It appears when switching from a larger document which has been modified to a smaller document.
- The problem does not exhibit when there is no lexical / semantic parsing and no HighlightingStyles applied.
- I'm not using the parsing service.
- You can catch and ignore the exception. Everything seems to be OK afterwards but of course I'd like the problem to be fixed.

What I suspect is that when the editor is displaying a document with a certain amount of text that is highlighted, and is switched to a document with a smaller amount of text, it is trying to refer to the old ranges for some reason.

To really prove this I have to add more sophisticated parsing and highlighting to my example - but that will be a fair bit of work.

Hi Paul,

Thanks for the info. When trying to dupe it, switch from a large document to a small one and perhaps have the selection in the large doc beyond the number of lines that are in the small one. It must be something in that sort of scenario that is happening. I'm not sure that parsing would make a difference based on the stack trace, but you never know until we can dupe it.

You should be able to debug this further if you take a full dump and then view the stack trace / program state using windbg.

Search for "production bugs" on google and you will see an article I wrote on this

More information on this... we're running into a similar thing (same stack trace class bugs out) with PrintPreview when UnicodeEnabled is false. Is UnicodeEnabled false in your apps as well?

Not sure if this bug I'm talking about is the same as the one you guys are posting about but they could be related since it's occuring in the same class. We will try and work on a fix for the PrintPreview one we can dupe before tomorrow's target release.

UnicodeEnabled was true. Tried it with false and there is no difference.

Further testing shows that:

- If Doc1 has more lines than Doc2
- If you edit Doc1 and make a change on the last line, then switch to Doc2, the exception occurs
- This is with 'advanced' lexical and semantic parsing and syntax highlighting. With vanilla text editing subject to no parsing / highlighting it does not happen.

I'll wait to see if you can find and fix this in V4.0.251. If not then I'll work on getting the minimal example up to doing the parsing and higlighting. Hopefully then it will exhibit the bug and I can send it over.

If you have an early version of 251 ready I'd be happy to test it.

So to verify, you need a language that uses the semantic parser service to dupe it?

I can now reproduce the problem in a simple example. It isn't anything to do with parsing and highlighting - sorry about that.

The problem occurs as described when switching from a modified longer document to a shorter one. The critical bit appears to be that Outlining.Mode is set to Automatic rather than None.

I'll send you the example.

Thanks for the sample project Paul. I was able to debug it and fix it pretty quickly. We are shooting to get the new build up tomorrow.

Excellent work guys, can't wait for the new release :)