Documents and Modifications

The biggest change I would like to see in document modifiation comes in the Undo space, but I guess it's related. I've never been a fan of how SE restores selection after performing an Undo. It behaves more like Notepad than something like Visual Studio.

Undo would be one of the things that is tied into all the core text model. How would you like to see things improved, could you make a detailed list? I know I have some info from you in the past on this too.

I'd basically like to see it work like Visual Studio. My first impressions are that the modifications also stores information about the view state of the editor (i.e. selection start/end offset). When you Undo a modification, it restores the document AND the view state.

I believe the challenge in the past is that modifications are stored on the Document class which is unaware of what is happening on the Editor View (that contains selection data).

That's true and modifications will still likely stay in the document model.

However perhaps there is a way we could pass the modification around to all the views to store some custom data in them? Any ideas on how best to do that or have another way to store the info while still keeping modifications in the document area?

One other related thing is the navigation points that VS has. For instance when pressing Ctrl+- to jump backwards through your navigation history. How is that tracked and is it somehow tied to the undo stack?

Bill, I'm curious as to what practical advantage a native WPF SyntaxEditor would give. As an experiment, I tried putting the Windows Forms SyntaxEditor onto a WPF window (using the WindowsFormsHost control) and it worked seemlessly. There were no issues with tabbing between WPF controls and the hosted SyntaxEditor, and the editor resized as smoothly as the WPF textboxes I had on the same window. In fact, I don't think there's any way an end-user could tell that the editor wasn't native WPF.

Obviously I must be missing something, or else you wouldn't be considering a WPF rewrite!

Joe

To tie the data together, perhaps one of two things needs to happen. Either the modification needs to have a property to store view information (which will be null when no view is avaialble), or the view will have to keep a collection of modifications and track the state of the view at each modification (and then restoring that view when the undo happens).

The Ctrl +- navigation isn't related to Undo stack because it gets updated just as you change your selection within the document. Move the caret to the beginning of a document and a new navigation point is created. There appear to be some tolerances that determine if you create a new nav point or just shift an existing nav point (i.e. move the caret to the next line will just shift the current nav point to that line instead of creating a new one). I implemented this feature to the best of my knowledge using SpanIndicators to track nav points in the document. Built-in support would certainly be welcome.

Quote:
Obviously I must be missing something, or else you wouldn't be considering a WPF rewrite!

I can see a few things that would be advantages in a WPF model.

1) winforms controls hosted in a WPF window are always "on top". This means a WPF tabbed document model with flyout 'unpinned' tool windows would show the SE on top of the tool windows when they fly out (i.e. the tool windows would fly 'under' the SE). Obviously this is suboptimal.
2) the WPF rendering model is 'cached', so this means the code for rendering the SE could potentially be much simpler. This would probably translate to simpler code and faster turnaround on feature development, in addition to possibly better performance and less bugs in a v1 release. BTW, I'm not saying SE turnaround is bad - it's actually incredible!
3) WPF is the way of the future and the less interop that is necessary in future applications the better. Also, some of the event and command support in WPF could be very useful to SE users.

Well these are the 3 major goals for SE next:

1) Support more platforms since SyntaxEditor is our flagship product. Platforms supported hopefully will be WinForms, WPF, Silverlight (looking into it) for editing, ASP.NET (CodeHighlighter), and a Windows Live Writer blog plugin for syntax highlighting (possibly).

2) Make all of those platforms use an improved document/parsing library assembly that has the same code regardless of platform. This assembly will likely be .NET 2.0-based so that it can support people still using .NET 2.0 only for WinForms and/or ASP.NET.

3) Improve the language building and maintenance capabiltities, meaning make possibly a standalone application that uses wizard steps to walk you through easily creating a language, then an IDE for maintaining it after that. And this would be for making the language lexical, semantic, and maybe even other features.

So the WPF platform implementation is just a part of the entire goal. Specific to WPF, everything Kelly said is spot on. While SE for WinForms works fine in WPF, it's not usable in docking window UI's since it will show on top of the WPF auto-hide flyouts, etc. It's certainly easier to do some neat effects with WPF, although the core text rendering is more difficult. WPF certainly is going to be the future... Microsoft wrote their core Expression tools in WPF, and is in the process of converting all of VS over to WPF in the coming years.

Additionally we get a lot of requests for a WPF native control and since we are a software company, we have to create products that people want. Since SyntaxEditor is our flagship product, it should support as many platforms as possible. Plus it would be really cool if we could have a Silverlight variation, based on at least a subset of the WPF variation. Imagine making Silverlight applications with a syntax highlighting editor. That could be very popular in itself.

Anyhow, again that is just a part of the design goals. The other things will affect and improve WinForms as well.

---

Back on topic... :)

I did some quick testing. It appears that only the active view is doing any sort of selection tracking for undo. Can you confirm that?

If that is the case, what if the modification tracked a Source property and maybe a SourceData property. The Source could be some kind of reference or id for the View and the SourceData could be some arbitrary data, like a TextRange indicating the selection. Then when an undo occurred, each view could look at the modification, see if the source is the view, then restore the proper selection if it is.

Alternate ideas...

1) We could just keep some static Int16-based number that incremented and rolled over when maxed out. Each view when created would store the next value. That could be used to identify the view, even though not guaranteed to be unique. However for these purposes, it doesn't matter too much if two views end up with the same ID. Maybe even a byte would be sufficient. Just trying to think of how to best store info for this feature with minimal memory.

2) Source could be a WeakReference to the view. This uses more memory but is the completely correct way.

3) SourceData could be a TextRange, or maybe instead we just store so bit flags. Like one for no selection. One for normalized selection and one for reversed selection. Really, aren't those the only three things that can happen? No wait... doing some testing in VS. If you highlight a word then do comment line, then undo, it restores the original selection. So does look like TextRange is needed.

---

For the caret navigation now... another thing is notice in the VS TextEditor options there is an option to include caret movements in the undo list. That's interesting but also seems to be separate from the other tracking.

For instance, if that option is on, I can undo and it goes through the list of places i either last made or removed a selection.

The Ctrl+- ignores that and doesn't seem tied to it at all. Have any logic ideas on what needs to be done to get the Ctrl+- working? How does it seem like MS tracks this internally? Looks like they are storing a text blurb with each location too. I could see text in their context menus which was next to that location in the document that I had later deleted.

I look forward to SE next supporting more platforms, and I think that being .Net 2.0-based is very beneficial. My single request would be that the WinForms version supports Mono 2.0 and the Silverlight version supports Moonlight. This makes the cross-platform story complete.

Quote:
I look forward to SE next supporting more platforms, and I think that being .Net 2.0-based is very beneficial. My single request would be that the WinForms version supports Mono 2.0 and the Silverlight version supports Moonlight. This makes the cross-platform story complete.

I would ask that SE only support Mono and/or Moonlight if doing so does not make the interface or functionality weaker on the 'real' .NET and Silverlight platforms. I would say that it is the responsibility of Mono and Moonlight's developers to ensure that SE is supported on their platforms. As an example, if there are windows API functions that are needed in order to make the WinForms version more usable or easier to maintain, I would certainly not want to see those features be less functional or harder to maintain in order to ensure compatibility with Mono.

I'm not trying to start a flame war here, just trying to make sure priorities are set in a realistic way, since I would expect that most people who care about Mono functionality aren't really interested in paying for SE anyway.

Perhaps some of the things that necessitated direct WinAPI calls were hangovers from .NET 1.1? I would say it would definitely be worth looking, because if those dependencies can be removed because .NET 2.0 has native support for them, then that's the best of both worlds surely?

Or is .NET 1.1 still a viable target?

I agree that SE should not be made 'weaker' in any way. Foremost priority should be to MS .Net, but aiming for Mono support should be attempted. Running Moma over the assemblies quickly shows the areas that need more inspection (http://www.mono-project.com/MoMA).

I don't understand your comment about people who care about Mono functionality not being interested in paying for SE anyway. I am a paying customer and the reason I want Mono support is to make my commercial .Net applications cross-platform. My payware commercial applications appeal to users on Mac OSX (and some on Linux). I certainly think that Mac OSX users are not stingy with paying for software - but they will not pay for SE anyway, they will pay for my products and I will pay for SE.

Anyway, to sum up, I am only looking for Mono support for purely selfish commercial reasons, nothing to do with FOSS ;-)

Quote:
Perhaps some of the things that necessitated direct WinAPI calls were hangovers from .NET 1.1? I would say it would definitely be worth looking, because if those dependencies can be removed because .NET 2.0 has native support for them, then that's the best of both worlds surely?

Or is .NET 1.1 still a viable target?

I certainly don't think that .NET 1.1 is still a viable target. As for whether the API calls can be removed due to new features replacing them in 2.0, I would say the following regarding the control design:

1) functionality, features, ease of use, and viability of the product are the highest priority
2) maintanance, bugfix turnaround, and speed at which new features can be introduced is priority #2.
3) cross-platform compatability (meaning Mono / etc., not WinForms v WPF) should be a distant 3rd place.

Given that these priorities are kept in mind, it's certainly nice if there are less dependencies on the Win32 API, but use of those API calls should be made in order to satisfy one of the higher priorities at the expense of lower ones, rather than eliminating them in order to satisfy one of the lower priorities.

Hmmm not sure I agree - that sounds a bit hard headed.

I would say if eliminating the WinAPI calls satisfies 3 without impinging on 1 or 2, then it is worth doing.

It does open up SE to a lot of new possibilities, and potentially new revenue streams for Actipro (because of the widened audience) and I for one would certainly welcome the ability to distribute my apps for Linux...

Mono does support many P/Invokes to the platform API. Others can be added - the developers just need to know which ones are currently missing so they can add support for them. So making SE next play nicely with Mono doesn't mean removing all API calls - it just means identifying those API calls that are not currently supported and alerting the Mono developers about them so that support for them can be added to Mono.

So, making SE next fully cross-platform doesn't mean changing anything. Just keep track of what is not working and let the Mono team know.

Quote:
I would say if eliminating the WinAPI calls satisfies 3 without impinging on 1 or 2, then it is worth doing.

Matt, either you misunderstood what I was saying, or I said it very poorly, or both :)

I agree with you, if (1) and (2) aren't affected by a change that satisfies (3), then by all means do it - I'm just saying don't let (3) take priority over (1) or (2).

Yep - I agree 100%, absolutely. :)

Hey all, thanks again for the feedback but I do have one request. If you have comments that are not really related from the original post in the topic, I'd appreciate it if you post a new forum topic with the subject clearing indicating what your comments are about.

For instance, in this topic which was supposed to be about core document text-related desired features, we've talked about WPF, Mono, and more. :) It just makes it harder to find appropriate information when we come back and review past comments if we all don't do that.

Plus down the road when we do want to come back and see what you all were saying about Mono support, we won't know to look in the "Documents and Modifications" topic.

That being said, let me post our reply to the platform comments. If there are any more on that subject, please post a new topic on it instead. Keeping the posts organized and on-topic will help us all since we'll be able to locate what we're looking for faster. Thanks!

---

Our plan is to drop .NET 1.1 support with this next version so we can finally start using generics. Yay! :) Microsoft is on .NET 3.5 already so sticking with .NET 2.0 isn't ideal either but I have a feeling a lot of WinForms clients are still on 2.0.

We do have to use some API calls since .NET doesn't support everything necessary to implement the product correctly. However perhaps a move to .NET 2.0 will allow us to use some newer framework objects that weren't there before to accomplish some of these things. The GDI ones in particular may be able to be done with the TextRenderer classes. However still I believe our calls are more optimized for what we do and changing our code to use TextRenderer may slow things down. TextRenderer calls the same API's ours does more or less last time I looked but has to do some additional wrapping. As for how much of a difference it is, I'm not sure.

Thanks for posting about that other Moma application Gareth, I wasn't aware of that. I'll have to check it out once I get back to the point where it makes sense to review this.