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)
