微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

c# – 当存储在Application.Resources中时,为什么Freezables已经被冻结并且具有null Dispatcher(与Styles相同)?

我对此非常困惑,它开始让我质疑我对 WPF资源系统的全面理解

我有一个多窗口应用程序,其中每个Window派生对象在一个单独的线程上运行,并带有单独的调度程序.

Thread t = new Thread(() => {
    Window1 win = new Window1();
    win.Show();
    System.Windows.Threading.dispatcher.Run();
});
t.SetApartmentState(ApartmentState.STA);
t.Start();

我有一个Dictionary1.xaml资源字典,里面有一个名为Style的对象(它只是将Background属性设置为Red,并以TextBox为目标).在我的App.xaml中,我通过ResourceDictionary.MergedDictionaries集合引用了Dictionary1.xaml.在我的其他窗口的XAML中,我有一个StaticResource到文本框控件中的样式键,它可以工作.

我可以打开多个窗口,但不应该遇到跨线程错误?在其中一个窗口类的构造函数中,我这样做了:

Style s = (Style)TryFindResource("TestKey");
Console.WriteLine(((Setter)s.Setters[0]).Property.Name);    // no problem
s.dispatcher == this.dispatcher    // false

由于Style对象是从dispatcherObject派生的,这是否意味着它只能由拥有它的线程访问?如果在ResourceDictionary中定义了一个对象,这是不是意味着认情况下它是一个静态实例?这怎么可以工作?为什么我没有遇到跨线程错误

(我错误地报告了一个问题,因为我删除一个由其他东西引起的交叉线程错误)

我对此感到非常困惑 – 我认为只有冻结的Freezable对象才能跨线程共享.为什么我可以在其他线程上访问dispatcherObject?

解决方法

所以我最终得到了一个答案 – 我挖掘了很多.NET框架代码并得出以下结论:

当资源字典是应用程序级别的字典,主题字典或只读时,存储在资源字典中的所有项目都将被“密封”

if (this.IsThemeDictionary || this._ownerApps != null || this.IsReadOnly)
{
    StyleHelper.SealIfSealable(value);
}

... 

internal static void SealIfSealable(object value)
{
ISealable sealable = value as ISealable;
if (sealable != null && !sealable.IsSealed && sealable.CanSeal)
{
    sealable.Seal();
}
}

“密封”一个对象本质上使它成为不可变的,并通过ISealable字典实现 – 实际上Freezable通过调用Freeze()来实现它的密封行为!样式也实现它,它的实现可以防止修改Setters或Triggers集合. ISealable由许多类实现!

public abstract class Freezable : DependencyObject,ISealable
public class Style : dispatcherObject,INameScope,IAddChild,ISealable,IHaveResources,IQueryAmbient

更重要的是,我见过的每个WPF类中的每个Seal()实现(到目前为止)调用dispatcherObject.DetachFromdispatcher(),它将调度程序设置为null! (Freeze()内部也调用它)

“Sealing”似乎实现了通常被宣传为Freezable独有的不可变性行为,但实现ISealable的对象将表现出相同的行为并且是线程安全的 – Freezables具有区分它的其他行为(例如,子属性通知更改)

总而言之,“密封”对象实际上使得它可以跨线程共享,因为如果每个对象都存在于应用程序级别或主题资源字典中或者只读资源中,则会自动从其调度程序中分离它们.字典

要验证此结论,请反映ResourceDictionary并查看设置ResourceDictionary的逻辑父级的AddOwner()方法(例如,FrameworkElement,FrameworkContentElement或Application)

这就是为什么可以从其他线程访问画笔和Style对象的原因,因为资源字典被合并到Application.Resources中,因此全部自动密封 – 毫不奇怪地将这些资源放在Window级别将导致通常的跨线程异常.

我想你可以推断,ISealable是使WPF对象可以跨线程和只读共享的原因,尽管从dispatcher技术上分离不是协议的要求(就像dispatcherObjects不需要在每个调用调用VerifyAccess()一样)因为它在技术上取决于每个对象实现它自己的Seal()行为,并且ISealable和dispatcher之间没有直接的关联

原文地址:https://www.jb51.cc/csharp/244461.html

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐