How does split view work in VS Orcas

  • Article

As you probably know from my earlier blog post Visual Studio Orcas (and future Visual Web Developer Express) now have Split view similar to the Expression Web designer. Although Visual Studio is using largely same designer, it provides its own Source markup editor. Therefore split view behavior is somewhat different from Expression and former FrontPage.

The important part is that many tools, especially in CSS area, are provided by the designer. Designer is also responsible for instantiating controls on the page so you can edit their properties in the Properties window and bind events in the Events tab. When you first open page in Source view, the designer is not loaded for performance reasons. Here is how VS looks like after page is open:

You can see that CSS tools are empty, Properties windows does not have Events button and Properties dropdown display ASP.NET button as <BUTTON> Button1. Basically, you are getting VS 2005 editing experience. Important difference however, is that after you switch to Design view at least once, designer is activated and remains loaded even after you switch back to Source view. This allows us to keep unified undo stack which does not collapse all Design view actions into a single 'Design View Changes' undo item as it happens in VS 2005. It also allows you to use designer-provided tools in Source view. Here is how VS Orcas looks like when you switch from Source view to Design and back.

It is important to understand that designer-dependent tools only work when designer is syncronized with the Source view contents. Automatic syncronization happens when you:

1. Switch to Design view.
2. Activate design pane in Split view.
3. Save the file.
4. Change control ID that causes refactoring in code with forced file save.

If I simply type in Source view, design view goes out of sync and tools revert to the Source-view driven behavior. In Split view a special banner appears:

 

You can sync view by saving the file, by clicking on the banner (click does not activate the designer, only loads it with the new content) or by using new Synchronize Views command available in the View menu. In the current bits some tools remain enabled depending on what changed in the file, we are still working on exact syncronization scenarios.

When designer is in sync with Source, all tools are available because Source and Design views maintain selection syncronization. Designer always updates selection in Source view and Source view pushes caret position to the designer on idle. When you place caret in asp:button tag in Source view, caret position will be sent to the designer which, in turn, will locate and select the correspondent control instance and you'll see live control instance in the Properties window. Live control instance makes Events tab and all other control-provided tools, editors and wizards available in Source view.

When you use designer-provided tools in Source, change goes to the designer and then persists to the Source view. Some people expressed concerns that designer may be changing markup formatting as it used to happen in VS 2003. Let me assure you that FrontPage-base designer never had issues with reformatting user markup, so no worries :-).

In VS Orcas view switch is practically gone. When you switch views we only resize the window hiding inactive view. However, it is still there and maintains its functionality. For example, when you are editing page in Design view, changes are sent to the Source view immediately, VS Orcas does not wait until the view switch and instead behaves like Expression Web or FrontPage 2003.When you are moving caret in Source view, selection changes in designer even if it is invisible (i.e. you are in Source view).

Comments

  • Anonymous
    January 23, 2007
    The comment has been removed

  • Anonymous
    January 23, 2007
    That's part of the CTP/Beta program and this blog :-) We want to hear feedback from you. Actually, showing same tools all the time is simpler, but it will slow down IDE startup and opening of the page as designer needs to get loaded and initialized, like in Expression Web.

  • Anonymous
    January 23, 2007
    I very much see the point that it should not slow down IDE startup time. I might not want to use any Web Dev features in some cases and then that performance hit would really be not good. But I think a perf hit when I open the first html/aspx file would be fine. I mean, in the vast majority of cases I will want to use the CSS/property/whatever tools anyways when I open up such a file. If that is so, i.e. if in the majority of cases when a aspx file is opened people will also use those tools (you should be able to find that out via customer user data during the CTP, right?) then the perf trade of seems to be "opening of html + loading of tools" vs. "opening of html, switching to design view + loading of tools + switching back to source view". The latter by definition would be slower ;)

  • Anonymous
    January 23, 2007
    There is new option 'Open in Split view' which keeps Source ane active and yet loads the designer. Will that fit you needs?

  • Anonymous
    January 23, 2007
    I think having do switch to/from will be percieved more as a flaw than a feature. I know that I would like to see the CSS features ready to go regardless of what view I opened. If this was enabled, maybe there could be an option to turn it off.

  • Anonymous
    February 23, 2007
    The comment has been removed

  • Anonymous
    February 23, 2007
    New designer is not based on any browser. It is based on former FrontPage and is essentially same engine as in Expression Web. Browser-based engines are not well suites for building Web designers at least not directly. IE-based engine has its issues I blogged about back in 2004 here: http://blogs.msdn.com/mikhailarkhipov/archive/2004/05/16/132886.aspx Gecko based editor has similar issues, at least some time ago: http://blogs.msdn.com/mikhailarkhipov/archive/2004/08/22/218695.aspx Generally speaking browser code base has different priorities and optimizations as opposed to the designer. I don't think DreamWeaver or GoLive are based on a browser. Besides, we want to have excellent support for ASP.NET controls at design time which is very specific requirement. As for automatic synchronization from Source to Design as you type, we are still looking into it.

  • Anonymous
    February 25, 2007
    Thanks for the answers. It was my understanding that at some point the designer in Dreamweaver was based on Opera. Doesn't implementing a new rendering engine for the designer cost a lot of resources, thus money?  And how well will it support displaying sophisticated CSS? I guess I'll be trying out the latest Orcas CTP very soon to find out... What's the best way to give feedback, ASP.NET forums?

  • Anonymous
    February 25, 2007
    I seriously doubt DW is based on Opera... DW is quite mature software written by Macromedia while Opera is produces by a separate Norwegian company... New rendering engine is based on former FrontPage, so it is not written from scratch. CSS display is a complex piece and it has been significantly improved compared to the FP 2003. Yes, developing and supporting designer requires decent resources, but nothing is cheap in serious software development anyway :-) Orcas forum is here http://forums.asp.net/1112/ShowForum.aspx

  • Anonymous
    February 26, 2007
    This is the best source I could find that mentions Dreamweaver is based on Presto, the layout engine from Opera. http://www.opera.com/pressreleases/en/2002/07/20020702.dml But only for Mac...

  • Anonymous
    March 10, 2007
    The first post into my weblog... with a few words about me and this weblog, what you might expect to