【WPF学习】第二十七章 Application类的任务

　　上一章介绍了有关WPF应用程序中使用Application对象的方式，接下来看一下如何使用Application对象来处理一些更普通的情况，接下俩介绍如何初始化界面、如何处理命名行参数、如何处理支付窗口之间的交互、如何添加跟踪文档以及如何创建单示例应用程序。

一、显示初始化界面

　　WPF应用程序的运行速度快，但并不能在瞬间启动。当第一次启动应用程序时，会有一些延迟，因为公共语言运行时(Common Language Runtime,CLR)首先需要初始化.NET环境，然后启动应用程序。

　　这一延迟未必成为问题。通常，只需要经历很短的时间，就会出现第一个窗口，但如果具有更耗时的初始化步骤，或者如果只是希望通过显示打开的图像应用程序显得更加专业，这时可使用WPF提供的简单初始界面特性。

　　下面是添加初始界面的方法：

　　（1）为项目添加图像文件（通常是.bmp、.png或.jpg文件）。

　　（2）在Solution Explorer中选择图像文件。

　　（3）将Build Action修改为SplashScreen。

　　下次运行应用程序时，图像会立即在屏幕中央显示出来。一旦准备好运行时环境。而且Application_Startup方法执行完毕，应用程序的第一个窗口就将显示出来，这时初始化界面图像会很快消失(约需300毫秒).

　　该特性听起来很简单，事实上也确实如此。只需要记住显示的初始化界面没有任何装饰，在它周围没有窗口边框，所有由你决定是否为初始界面图像添加边框，也无法通过显示一系列的多幅图像或动画让初始化图像显得更富有想象力的效果。如果希望得到这种效果，需要采用传统方法：创建在运行初始化代码的同事显示你所希望的图像界面的启动窗口。

　　顺便提一下，当添加初始界面时，WPF编译器会自动生成的App.g.cs文件添加与下面的类似的代码：

SplashScreen splashScreen = new SplashScreen("images/blue.jpg");
//Show the splash screen
//The true parameter sets the splashScreen to fade away automatically
//after the first window appears
splashScreen.Show(true);
 
//Start the application
AssemblyResources.App app = new AssemblyResources.App();
app.InitializeComponent();
app.Run();
//The splash screen begins ites automatic fade-out now.

　　也可自行编写这一剪短逻辑，而不死使用SplashScreen 生成操作。但有一点需要指出，可以改变的唯一细节是初始界面褪去的速度。为此，需要项SplashScreen.Show()方法传递false(从而使WPF不会自动淡入初始化界面)。然后由你负责通过调用SplashScreen.Close()方法在恰当的时机隐藏初始界面，并提供TimeSpan值来指示经过多长时间淡出初始化界面。

二、处理命令行参数

　　为处理命令行参数，需要相应Application.Startup事件。命令行参数是通过StartupEventArgs.Args属性作为字符串数组提供的。

　　例如，假定希望加载文档，文档名作为命令行参数传递。在这种情况下，有必要读取命令行参数并执行所需的一些额外初始化操作。在下面的示例中，通过响应Application.Startup事件实现了这一模式。在该例中，没有在任何地方设置Application.StartupUri属性——而是使用代码实例化窗口。

public partial class App : Application
    {
        // The command-line argument is set through the Visual Studio
        // project properties (the Debug tab).
        private void App_Startup(object sender, StartupEventArgs e)
        {
            // At this point, the main window has been created but not shown.
            FileViewer win = new FileViewer();
 
            if (e.Args.Length > )
            {
                string file = e.Args[];
                if (File.Exists(file))
                {
                    // Configure the main window.
                    win.LoadFile(file);
                }
            }
 
            // This window will automatically be set as the Application.MainWindow.
            win.Show();
        }
    }

<Application x:Class="LoadFromCommandLine.App"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Startup="App_Startup">
    <Application.Resources>
 
    </Application.Resources>
</Application>

App.xaml

　　上面的方法初始化主窗口，然后当App_Startup()方法结束是显示主窗口。上面的代码假定FileViewer类有名为LoadFile()的共有方法。这只是一个示例，它只读取并显示指定文件的文本。

三、访问当前Application对象

　　通过静态的Application.Current属性，可在应用程序的任何位置获取当前应用程序实例，从而在窗口之间进行基本交互，因为任何窗口都可以访问当前Application对象，并通过Application对象，并通过Application对象获取主窗口的作用：

Window main=Application.Current.MainWindow;
MessageBox.Show("The main window is "+main.Title);

　　当然，如果希望访问在自定义主窗口类中添加的任意方法、属性或事件，需要将窗口对象转换为正确类型。如果主窗口的自定义类MainWindow的实例，可使用与下面类似的代码：

MainWindow main=(MainWindow)Application.Current.MainWindow;
main.DoSomething();

　　在窗口中还可以检查Application.Windows集合的内容，该属性提供了所有当前打开窗口的引用：

foreach(Window window in Application.Current.Windows)
{
    MessageBox.Show(window.Title+" is open.");
}

　　实际上，大多数应用程序通常使用一种更具结构化特点的方式在窗口之间进行交互。如果有几个长时间运行的窗口同事打开，并且它们之间需要以某种方式进行通信，在自定义应用程序类中保存这些窗口的引用可能更有意义。这样，总可以找到所需的窗口。与此类似，如果有基于文档的应用程序，那么可选择创建跟踪文档窗口的集合，而不是跟踪其他内容。

四、在窗口之间进行交互

　　整如在前面已经看到的，自定义应用程序类是放置响应不同应用程序事件的代码的好地方。应用程序类还可以很好地达到另一个目的：保存重要窗口的引用，使一个窗口可访问另一个窗口。

　　例如，假设希望跟踪应用程序使用的所有文档窗口。为此，可在自定义应用程序类中创建专门的集合。下面是使用泛型列表集合保存一组自定义窗口对象的示例。在这个示例中，每个文档窗口由名为Document类的实例表示：

 public partial class App : Application
    {
        private List<Document> documents = new List<Document>();
 
        public List<Document> Documents
        {
            get { return documents; }
            set { documents = value; }
        }
    }

　　现在，当创建新文档时，只需要记住将其添加到Documents集合中即可。下面是响应按钮单击事件的事件处理程序，该事件处理程序完成了所需的工作：

private void cmdCreate_Click(object sender, RoutedEventArgs e)
        {
            Document doc = new Document();
            doc.Owner = this;
            doc.Show();
            ((App)Application.Current).Documents.Add(doc);
        }

　　同样，也可在Document类中响应Window.Loaded类这些事件，以确保当创建文档对象时，总会在Documents集合中注册该文档对象。

　　现在，可在代码的其他任何地方进行集合来遍历所有文档，并使用公有成员。在该例中，Document类包含用于更新显示的自定义方法SetContent();

private void cmdUpdate_Click(object sender, RoutedEventArgs e)
        {
            foreach (Document doc in ((App)Application.Current).Documents)
            {
                doc.SetContent("Refreshed at " + DateTime.Now.ToLongTimeString() + ".");
            }
        }

<Window x:Class="WindowTracker.MainWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="WindowTracker" Height="300" Width="300"
    >
    <StackPanel>
      <Button Click="cmdCreate_Click" Margin="10,10,10,5" Name="cmdCreate">Click to Create a Document</Button>
      <Button Click="cmdUpdate_Click" Margin="10,5,10,10" Name="cmdUpdate">Click to Refresh the Documents</Button>
    </StackPanel>
</Window>

MainWindow.xaml

<Window x:Class="WindowTracker.Document"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="WindowTracker" Height="78" Width="209"
    >
    A new document.
</Window>

Document.xaml

public partial class Document : Window
    {
        public Document()
        {
            InitializeComponent();
        }
 
        public void SetContent(string content)
        {
            this.Content = content;
        }
    }

Document.xaml.cs

　　下图显示了最终效果图。最终结果谈不上华美，但这种交互方式值得注意——演示了一种通过自定义应用程序类在窗口之间进行交互的安全规范的方式。这种方式比使用Window属性要好，因为是强类型，只包含Document窗口（而不是包含窗口应用程序中所有窗口的集合）。通过这种方式还可使用另一种更有用的方式对窗口进行分类。例如，可使用字典集合，通过键名更方便地查找文档。在基于文档的引用程序中，可通过文件名来索引集合中的窗口。

五、单实例应用程序

　　通常，只要愿意就可以加载WPF应用程序的任意多个副本。某些情况下， 这种设计时非常合理的。但在另外一些情况下，这可能会成为问题，当构建基于文档的应用程序时更是如此。

　　对于单实例应用程序，WPF本身并未提供自带的解决方法，但可使用几种变通方法。基本技术时当触发Application.Startup事件时，检查另一应用程序实例是否已在运行。最简单的方法是使用全局的mutex对象（mutex对象时操作系统提供的用于进程间通信的同步对象）。这种方法很简单，但功能有限。最重要的是，应用程序的新实例无法与已经存在的实例进行通信。对于基于文档的应用程序而言这确实是一个问题，因为新实例可能需要告诉已经存在的应用程序实例打开某个特定的文档（如果该文档是通过命令行参数传递的）。