文章导读1、应用程序的类型2、窗体（Window）3、Page类4、导航窗体（NavigationWindow）5、XAML浏览器应用程序6、Windows Presentation Foundation资源 　　XAML浏览器应用程序

　　NavigationWindow、页面和超链接为用户在独立的应用程序中获得浏览器样式的用户体验提供了一条很好的途径。总而言之，NavigationWindow是一个浏览器，虽然它没有目前的浏览器所带有的所有功能（例如收藏夹、分页浏览等等）。由于大多数用户都有浏览器的知识，他们对提供同等能力、甚至集成浏览器的应用程序的感觉会更好。如果你的应用程序从浏览器寄宿和超链接驱动的环境中受益，那么Windows Presentation Foundation XAML浏览器应用程序（XBAP）是我们应该努力的方向。

　　为了建立一个XBAP示例应用程序，需要在Visual Studio 2005中建立一个新的.NET框架组件3.0 Web浏览器应用程序，并复制示例NavigationWindow文件，就完成工作了。作为结果生成的应用程序将寄宿在Internet Explorer中运行，如图11所示。

图11：寄宿在Internet Explorer中的应用程序

　　XBAP可以在内部网或Internet上的Web服务器上发布和载入。这使得我们能够使用ClickOnce部署（它包含在.NET框架组件3.0中）。使用ClickOnce的时候，MSBuild生成最终用户运行的可执行文件和ClickOnce用于下载和载入可执行文件的两个清单（manifest）文件。其中一个就是应用程序清单；它带有.xbap文件扩展名，是用户希望载入XBAP应用程序时实际浏览的内容。请注意，载入过程对于用户来说是无缝连接的--浏览XBAP应用程序的体验与浏览任何浏览器中运行的应用程序的体验是一样的。

　　从Internet上载入一个应用程序的时候，安全性是一个重要的因素。由于这个原因，XBAP是不会被安装的。而且，XBAP利用.NET框架组件的代码访问安全性（CAS），通过强制的安全性平台防止用户受到恶意代码的攻击--对于从Internet区域载入的应用程序来说，XBAP只能执行许可的事务，是一组受限的操作。而且，如果XBAP试图执行超出Internet区域许可的功能，就会产生异常，应用程序会停止执行。

　　Internet区域许可阻止了Windows Presentation Foundation 1.0中的大量功能，包括显示窗体、使用SaveFileDialog（保存文件对话框）、注册表访问、通过脚本访问HTML文档对象模型（DOM）。尽管牺牲了这么多特性来保证CAS保护的XBAP应用程序的利益，你仍然会发现自由支配Windows Presentation Foundation真的非常酷。

　　框架（Frame）

　　框架把浏览器样式的用户体验带入了内容之中，它可以被其它的导航器（标准的或基于浏览器的、菜单或超链接驱动的）寄宿。由于它具有很大的灵活性，因此在决定如何使用它的时候，应该由已有的用户体验来指导。

　　标准的、菜单驱动的应用程序并没有提供导航文档样式内容（例如帮助文件）的最佳模型。超链接驱动的方法可能更加适合，并且链接可以轻易地嵌入标准的应用程序窗口，如图12所示。这是使用下面的标记来实现的：

＜!--HelpDialog.xaml (markup)--＞ ＜Window ... ＞ ＜DockPanel＞ ＜TextBlock Padding="20,20,20,20" DockPanel.Dock="Top" TextWrapping="Wrap" FontSize="15" FontWeight="Bold" ＞ Box Application Help ＜/TextBlock＞ ＜Frame Padding="20,0,20,0" Source="HelpPageContents.xaml" /＞ ＜/DockPanel＞ ＜/Window＞

　　作为选择，框架可以像HTML IFRAME元素一样被寄宿在Windows Presentation Foundation页面的内容中，如图13所示。它的标记类似如下：

＜!--HelpPage.xaml (markup)--＞ ＜Page ... ＞ ＜DockPanel＞ ＜TextBlock Padding="20,20,20,20" DockPanel.Dock="Top" TextWrapping="Wrap" FontSize="15" FontWeight="Bold" ＞ Box Application Help ＜/TextBlock＞ ＜Frame ... Source="HelpPageContents.xaml" /＞ ＜/DockPanel＞ ＜/Page＞

　　　　　
　　图12：独立窗体中的可浏览内容

　　在默认情况下，当一个框架寄宿在内容中的时候，它就直接或间接地寄宿在另一个导航器中，可以使用父导航器所管理的导航服务。这意味着页面的导航历史存储在它的父导航器的导航历史中，与父导航器本身的导航历史存储在一起。因此，在父导航器的导航历史能够导航之前，框架的导航历史必须向前和向后导航这些内容。但是，当父导航器寄宿的内容在多个页面之间共享的时候，这并不是坏事。这类似于ASP.NET的主页面/子内容。

图13：内容中寄宿的框架

　　另一方面，如果框架中的页面只由单个逻辑内容组成（例如一个帮助文件而不是多个帮助页面），这种导航就非常痛苦了。一旦用户进入帮助并导航到适当的帮助页面，它一般不希望通过所有浏览过的页面导航回去，而是直接返回先前的父页面。在这种情况下，你可以通过设置JournalOwnership属性，指示框架使用自己的导航历史，如下所示：

＜Page ... ＞ ... ＜Frame ... JournalOwnership="OwnsJournal" /＞ ... ＜/Page＞

　　JournalOwnership属性是用于设置框架使用哪个"journal（导航记录）"的（内部的Journal类型封装了Windows Presentation Foundation中的导航历史），它可以是下面几个JournalOwnership枚举值之一：

enum JournalOwnership { Automatic, // 如果由框架或NavigationWindow 寄宿，是"UsesParentJournal" // 否则是"OwnsJournal"（默认的）。 OwnsJournal, // 框架管理导航历史 UsesParentJournal // 框架的宿主管理导航历史 }

　　当框架拥有自己的导航历史的时候，它会显示自己的导航用户界面，如图14所示：

图14：带有自己的导航历史的框架

相关搜索：