Indent command becomes extremly slow

Stéphane,

Yes that is something we are aware of and have been working on improving. There are 5000 individual changes in the example you gave, which is the reason why it takes so long.

That being said, in the new text/parsing framework we've been prototyping with our WPF version, this is something we've worked on. We can indent 5000+ lines in about 1.2 seconds in the current WPF alpha build. That's even much faster than VS 2008 can do, for a C# doc at least.

Down the road we hope to port this text/parsing framework to a future SyntaxEditor for WinForms version, but it has some major design changes and still needs work to bring the feature set up to what is currently in SE4. The speed increase for your particular issue are part of those major design changes we've made to help performance.

You are right, that tip in the docs will blow away existing indicators. Our indent code used to do that however users complained, which is why we switched it to individual transactions instead like it is now.

Hi and thanks for your answer,

the problem is that in our application we are attached to textChanged event.
I gave you the example with 5000 lines but in our case it takes 10 seconds for 1000 lines.
Further more, it crashes the application if you press Ctrl+Z which is not acceptable for the user.

We do need a solution/patch/workaround to this problem (without waiting/thinking of a migration to WPF !)

I tried to stop the semantic parser, to suspend painting, suspend layout but it has not effect.

We are facing the same problem when we are developing our own FormatTextRange.
Is there a way to prevent the document to raise the event ?
Something like document.raiseTextChanged = false

Thanks for your help

Stéphane

[Modified at 05/05/2009 10:17 AM]

Stéphane,

I was just mentioning that we have been working on improving speed of multiple replace transactions with the text/parsing framework that we're prototyping with the WPF SyntaxEditor. The WPF version is designed such that the text/parsing framework is in its own .NET 2.0 assembly so that it can be cross platform and be used by WinForms down the road. It has no dependencies on WPF UI. I wouldn't expect you to move to WPF for this, I'm merely indicating that we've made our next gen text/parsing framework so that it can be used in WPF and WinForms. The part that will take time is altering the WinForms UI code to work with it and have the same features and more that are in SyntaxEditor 4.0.

Part of the updated design I'm talking about is that we have altered things so that you can batch up multiple replace operations into a single "text change". This means that a single text changed event can fire for 1000 replace operations, which sounds like what you want. But again the downside is that this is not yet available for WinForms and it has taken a major effort to develop this new model since there are a lot of other new enhancements that go along with it.

There isn't a way to suspend the text changed event right now, however if some code you have in response to it is slowing everything down, you could simply add a flag on your end as to whether to do any processing in that event or not. Thus you'd be able to suspend it from your side.

Hi Bill,

Even if we remove our code it's extremely slow and the CTRL+Z crashes the application.
As far as I understand we have no possibility to implement a workaround in our code using the current version and you don't plan to correct it.

Eight month ago I submitted a bug regarding the lines indicators and I have no news (http://www.actiprosoftware.com/Support/Forums/ViewForumTopic.aspx?ForumTopicID=3246)

Shall I concluded that SyntaxEditor is no more supported ?

Anyway, I repeat it again, but we must imperatively find a solution to prevent this bug (even if it requires work on our side)

Thanks for your help

Stéphane

Stéphane,

If you email over a simple sample project we can take a look at it and see if we have any tips for you. However as mentioned, due to how v4.0 works, it can be slow with very large amounts of edits. Still even with that Ctrl+Z should not crash anything.

We have identified performance issues like what you are describing and that is specifically why we have been working the past number of months on making an improved text/parsing framework that will be cross-platform (WPF, WinForms, etc.). The next gen framework is geared to be fast and make speed improvements in a number of areas. So I would definitely not say SyntaxEditor isn't supported. Things like this issue are exactly why we're working on the next gen framework. However we are prototyping it out with the WPF version simply because there will be breaking changes and we wanted to nail those down first before migrating it into WinForms.

Our support on existing products is a bit slower over the last couple months since as mentioned a couple weeks ago in that other topic, we are under a lot of pressure to get WPF Studio 5.0 out. The main holdup there is completing SyntaxEditor for WPF's public beta. We estimate 2-3 weeks of work left. And as indicated in that other post, we'll be able to look more at existing product enhancements after that is released, so please check back with us then.