SD2-1234, titled "Create common way to handle in-memory representations of files that have multiple views" is the issue tracker entry behind a major refactoring of the IViewContent interface.

The major new feature introduced is that now it is possible to open a file in multiple view contents at the same file (using "Open with"). Both IViewContent instances will edit the same underlying file - when you switch between them, one view content will display the unsaved changes of the other; pressing Ctrl+S in one of them will save both.

Now how is this possible? There must be some data structure shared by both view contents. Since the view contents might not know anything about each other (both could be independently developed AddIns), this data structure must work on the lowest possible level: bytes. It's simply a MemoryStream.

Of course the view contents cannot serialize their content on every change; so a view content may have local changes in a higher-level data structure (text editor buffer, list of entries in resource file, etc). To ensure that such changes are correctly synchronized between view contents showing the same file, I introduced the concept of an active view content. The active view content is the only view content that may have such local changes. Thus, the active view content always has the most recent version of the file, and it is the only view content that is guaranteed to have the most recent version.

To represent files, I created the OpenedFile class. This class knows which view contents have opened it and knows which of them is the active view content. Usually every OpenedFile can have a different active view content; though it is possible for multiple OpenedFiles to have the same active view content if that view content opens multiple files - the refactoring also added support for view contents that are editing multiple files at the same time.

Now a quick overview of the SharpDevelop UI: The SharpDevelop main window is composed of a main menu, a tool bar, and the DockPanel of Weifen Luo's DockPanel Suite. In the dockable area, there are pads, which can be docked in groups at the sides of the SharpDevelop window; or can float somewhere (e.g. on a second monitor).
In the remaining space (not occupied by pads), workbench windows are displayed. The active workbench window can be chosen using the tabs at the top. There can be multiple visible workbench windows if a user drags a tab and docks it to the side of the remaining space.
Finally, each workbench window contains at least one view content. The active view content can be chosen using the tabs at the bottom.

So if you create a new Windows Application and open Program.cs and MainForm.cs, there are two workbench windows titled "Program.cs" and "MainForm.cs", but three view contents - "Program.cs - Source", "MainForm.cs - Source" and "MainForm.cs - Design".

Note that in the new IViewContent architecture, there are no secondary view contents. Now all view contents are equal, and they shouldn't care if they share a workbench window or not. Whether they will share a workbench window or not depends on how the view contents were created - there is still the difference between primary and secondary display bindings, which are responsible for creating view contents.

Now how do changes get from one view content to the other? It's quite simple: Whenever the user activates a view content (by clicking a tab at the top, by clicking a tab at the bottom, or by setting focus into another workbench window after the user docked a window to the side), that view content becomes the active view content for all files it has opened. The old active view content will be asked to save its content to a MemoryStream and the new active view content will be asked to load from that MemoryStream. This way, unsaved changes are transferred from one view content to another.

When the active view content for a file is closed, but there are other open view contents for that file, SharpDevelop will not ask the user to save the file. Instead, it will save the data from the view content being closed into a MemoryStream. After that, the OpenedFile has no active content. Only when one of the other view contents that have opened that file get activated by the user, that view content will load from the MemoryStream and thus will preserve unsaved changes from the closed view content. However, if the user closes all other view contents for that file without making them active (by middle-clicking, or using Window>Close all), SharpDevelop will ask the user if the file should be saved and write the MemoryStream content to disk if required.

The system sounds simple for view contents: they just have to be able to load and save; and it'll just work.

But it isn't that easy. The view contents must be able to load and save reliably at any time.

The user just did something invalid which cannot be saved and then switches to another view of the file? The view content is forced to save. It's not possible say "I don't want to save".

The user loads a .resx file in the text editor, changes something by hand that renders the file invalid XML, opens it in the resource editor, gets an error message, switches back to the text editor. Here the file is saved by the text editor, loaded in the resource editor, the user gets the error and switches back, the resource editor must save and the text editor will load again. The resource editor view content must support loading and saving invalid files unless you want this kind of round-trip to result in loss of user data.

If your view content is editing multiple files, it gets even more complicated: you must support loading and saving individual files reliably at any time, in any order. Sounds fun, right?

Well, if you don't get this right, the user looses data only when editing a file in multiple views simultaneously. In SharpDevelop 2.x, view contents were simply overwriting each other's data; in SharpDevelop 3.0 there's at least a chance that it works if all view contents are implemented correctly.

However, be warned that I didn't have the time to update all view contents in SharpDevelop to make use of the new model. There's still a class AbstractSecondaryViewContent that implements Load and Save so that they run through an underlying "primary" view content, so existing secondary view contents do not have to be completely rewritten (although they still need several changes). The text and resource editors are fine; use them to see how it should work. The forms designer does not yet use the new model, it uses AbstractSecondaryViewContent and still touches the Designer.cs file directly, resulting in bugs like SD2-1175.

But if you are writing a new view content, try to design it so that you can support loading and saving at any time. The AbstractViewContentHandlingLoadErrors class (which both the resource editor and the WPF designer use) can help you handling invalid files.

If your view content edits multiple files, it can get tricky to support loading and saving those independently. But if it is likely that a user will want to edit one that files separately while also using your multi-file view content, you will have to do it. It is possible in SharpDevelop 3.0, so that's an improvement over SharpDevelop 2.x.

By the way: the reason for all this is the settings designer (still not implemented): it edits both a .settings XML file and app.config, and it's very likely that the user has opened the app.config at the same time.

Post by Daniel Grunwald (we use the category to mark the author on this blog, but I'll repeat it from now on at the bottom of the post because some feed readers like Google Reader don't show the category)

Read the complete post at http://laputa.sharpdevelop.net/IViewContentRefactoringExplainedSD21234.aspx