嗨，我想通过textboxquantidadehoras.Text; datahorado.SelectedDate; correto.Desenvolvedor（从childwindow）到主页面中名为datagridhorastotais的网格，但是我无法将itemsource设置为“teste”形式的子窗口...任何想法？这是childwindow的代码
public partial class ChildWindow2 : ChildWindow, INotifyPropertyChanged
{
public class Horas : INotifyPropertyChanged
{
private string quantidadehoras;
private DateTime? datahora;
private string desenvolvedor;
public string Quantidadehoras
{
get
{
return quantidadehoras;
}
set
{
quantidadehoras = value;
NotifyPropertyChanged("Quantidadehoras");
}
}
public DateTime? Datahora
{
get
{
return datahora;
}
set
{
datahora = value;
NotifyPropertyChanged("DataHora");
}
}
public string Desenvolvedor
{
get
{
return desenvolvedor;
}
set
{
desenvolvedor = value;
NotifyPropertyChanged("Desenvolvedor");
}
}
#region
public event PropertyChangedEventHandler PropertyChanged;
private void NotifyPropertyChanged(string propertyName)
{
if (PropertyChanged != null) PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
}
public class Horas2 : ObservableCollection<Horas>
{
public Horas2()
{
}
}
}
#endregion
public ChildWindow2()
{
InitializeComponent();
}
public class quadrodehorarios : ObservableCollection<ChildWindow2>, INotifyPropertyChanged
{
}
private void OKButton_Click(object sender, RoutedEventArgs e)
{
Horas2 teste= new Horas2();
Horas correto = new Horas();
correto.Quantidadehoras = textboxquantidadehoras.Text;
correto.Datahora = datahorado.SelectedDate;
correto.Desenvolvedor =textboxDesenvolvedor.Text;
this.DialogResult = true;
}
private void CancelButton_Click(object sender, RoutedEventArgs e)
{
this.DialogResult = false;
}
private void comboBox1_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
}
private void textboxqtdhoras_TextChanged(object sender, TextChangedEventArgs e)
{
}
}
}
答案 0 :(得分：0)
如果我理解你要做什么......你可以使用Mediator模式（例如Event Aggregator）将子窗口中的事件（数据选择）传递给父窗口。这是StackOverflow question that covers the Event Aggregator。
答案 1 :(得分：0)
我今天晚上正在编写关于我的书的“事件聚合器”模式的章节，我开始收集我对这个主题的看法。如果你觉得你必须发表评论并给我本章的免费建议，那么我想你应该这样做（请）。我在这里和这里之前都写过这个模式。我还引用了一些我还没有写过的其他模式。 Ward Bell和John Papa都在博客上发表了这些模式。我明天晚上会在博客上讲述我的StoryTeller实施情况。
如果您是模式的新手，Event Aggregator对象将：
将多个对象的事件通道转换为单个对象，以简化客户端的注册。
从本质上讲，它是GoF Mediator模式的一种特殊形式。它是应用程序中的“中心”对象，您可以使用它在应用程序的不同部分之间进行解耦的“发布/订阅”消息传递。我已经将模式与WinForms应用程序，WPF与StoryTeller一起使用，甚至在网页中使用JavaScript（在我们为工作中的Web应用程序实现仪表板模式时非常重要）。
这是关于模式的题词：
注册。有人必须负责向事件聚合器中心注册监听器。 您可以通过依赖事件聚合器来让侦听器自己进行注册，这与Prism是惯用的。这很好，因为它在查看类时是否显而易见，无论它是否被注册为监听器。我不是这种方法的粉丝，因为我认为它很笨拙并且为每个监听器添加了重复的代码 - 重复的代码应该在弹出的任何地方标记出来。 您可以使用另一个对象，如“Screen Activator”（稍后将详细介绍此模式），将ViewModel / Presenters，屏幕或非UI元素注册为侦听器。这样做的好处是可以从执行实际工作的类（ViewModel / Presenter / service）中删除引导的责任。 这实际上只是2a，但您可以使用自定义“注册表”类在一个地方进行显式订阅者订阅。我喜欢 使用IoC工具的常规注册可以根据需要自动将对象添加到事件聚合器。我使用标记接口和StructureMap“拦截器”在StoryTeller中执行此操作。这是机械上“最简单”的，但增加了一些开销来理解这些部分的连接方式。但是，有一个很大的但是，惯例是黑魔法而不是明确的代码 发现性/可追溯性。事件聚合器是间接的一种形式，而间接几乎总是使系统更难理解。在某些时候，您肯定需要了解哪些对象正在发布以及哪些对象正在接收事件。强类型事件在这里是一个福音，因为使用R＃的“查找用法”等高级IDE功能可以相对容易地快速确定特定类型事件的发布者和订阅者。 CAB中的事件聚合器模拟依赖于字符串键并使故障排除更加困难。 JavaScript和其他动态语言中的事件聚合器实现将具有相同的问题。 诊断。对于我们这些使用静态类型语言的人，您可能希望添加可以按需生成的诊断报告，该报告可以扫描代码库并基于对事件聚合器的依赖性来识别发布者和订阅者。使用标记接口或常用超类型进行消息类可以使诊断更加容易。 事件过滤。简而言之，并非每个订阅者都关心某类事件的每个实例。例如，StoryTeller有几个小部件需要响应每个单独的测试事件（排队，执行，完成），但是各个测试屏幕仅响应涉及其特定测试的事件。在这种情况下，您需要担心如何过滤事件。过滤的责任可以是： 听众本身。听众知道它关心什么，所以让它决定是否继续处理事件。 在EventAggregator本身内过滤。您可以使用以下主题注册侦听器：EventAggregator.Register（this，myTest），但这是假设一个专门的事件聚合器“知道”主题。另一种方法是使用Predicate或Func进行注册，以在事件聚合器中进行过滤。我还在这个模式里面对StoryTeller进行一些实验。 我正在考虑让IoC拦截器或Screen Activator进行过滤事件注册。同样，重点是将设置屏幕的繁琐工作移出ViewModel / Presenter以保持ViewModel / Presenter相对干净 线程编组。让事件聚合器负责将回调到屏幕的回调处理回UI线程是非常方便的。 Prism Event Aggregator可以对您是否应该进行编组进行精细控制。当每一点性能都很重要时，最大控制可能会很好，但是再一次，它会让你在很难测试的部分代码中容易出错。 排队。此时我让StoryTeller EventAggregator只是同步处理事物，但是为了节省资源，可能需要在后台线程上运行事件发布或排队事件。 开放/关闭校长。使用Event Aggregator可以更轻松地向系统添加新功能，而无需修改现有代码，如果您依赖于没有事件聚合器的直接通信。对于进行增量交付的团队或多个团队并行处理同一系统的情况，这是一个重要问题。 垃圾收集：您的事件聚合器必须保留对所有订阅者的引用。当屏幕关闭时，这可能会给您带来一些严重的内存泄漏问题，但如果事件聚合器保留引用，则不会收集垃圾。您可以在事件聚合器内部使用WeakReferences来解决问题。另一种选择是显式取消注册侦听器。 WeakReference策略可能更可靠，但也有其自身的问题。如果您使用“Screen Conductor”来管理屏幕激活生命周期，那么显式取消注册并不是那么糟糕。后来还有更多...... 事件锁定。这里有两个问题： 有时忽略事件可能很有价值。我特别想到一个未激活/显示的选项卡上的屏幕的情况。假设此屏幕收到有关正在更新的金融市场数据的事件。在资源方面，更新隐藏屏幕显示的行为非常昂贵。当屏幕被停用和隐藏时，您可能希望静静地忽略或“锁定”事件。当然，这会增加一些复杂性，使隐藏屏幕“知道”在再次激活时自动更新。我认为这是“屏幕激活器”和“屏幕导体”模式发挥作用的地方。如果在用户激活选项卡时发生标准工作流，则“屏幕激活器”应该进行Activate（）调用。 在某些特殊情况下，您可能希望Event Aggregator在响应事件时“锁定”自身。当响应事件的窗口小部件发布其他事件时，这尤其重要。想一想在将屏幕绑定到新数据的过程中发布的“更改”事件。在这种情况下，事件聚合器应忽略新事件，直到第一个完成。 活动订购。事件按照到达事件聚合器的顺序完全处理可能很重要。例如，Chad＆amp;我去年遇到一个问题，订阅者收到一个事件，然后发布在原始事件到达所有订阅者之前处理的其他事件。某处可能存在代码味道，但事件排序可能是您需要考虑的事情。 一种尺寸并不适合所有：在一个应用程序中拥有多个事件聚合器通常是有利的。我经常发现当单个屏幕本身非常复杂时，使用在单个复杂“复合视图”中作用域的事件聚合器很有用。 仪表。 EventAggregator实际上是一个消息总线，具有与消息总线相同的优点。通过事件聚合器发送所有事件为您提供了一个非常集中的位置来放置检测代码。重复性较低的代码= =更少的错误和更高的生产力。
Prism EventAggregator怎么样？
许多人首先通过Prism中的实现接触Event Aggregator模式。对于我的普通读者来说，你可能会感到震惊（我说，感到震惊！）要知道我并不特别关心他们在棱镜中实施模式的方式。我认为Prism的实现是笨拙和难以使用的。我鄙视首先得到事件聚合器的习惯用法，然后检索一个我将听的“事件”对象。发布也是如此。我认为我有两个步骤（获取事件，然后发布）而不是仅仅说“IEventAggregator.Send（）”是很尴尬的。所有这些都是不必要的噪音代码，“get event，then listen / publish”增加了一点我写的每一个单元测试都有一些开销，包括监听或发送事件（更多模拟对象设置，这将比额外的生产代码更多）。不，这不是一个大问题，但噪音代码加起来，我可以删除由于基础设施而导致的每一点仪式/噪音代码都会让我更有效率，并且通过使代码更容易阅读来更轻松地处理代码。
我想要的只是去：
IEventAggregator.Send（消息）。没有其他的。 听众应该很少或最好是NO / ZILCH / NADA耦合到事件聚合器。 我认为Prism远比CAB好，但它仍然会遇到CAB遇到的一些问题。 Prism中EventAggregator的复杂性和尴尬直接是由于试图将EventAggregator推广到您能想到的每个可能的场景。您可以通过为您需要的东西定制更简单的东西，为您的应用程序创建更好的EventAggregator实现。至少，您至少可以在Prism的通用API周围放置一个特定于应用程序的包装器，以使它们更容易使用。我认为你可以牺牲Prism EventAggregator的一些灵活性，最终得到一个更简单的替代品。
不要将此视为对Prism本身的具体批评，因为真正的问题是广义的应用程序框架是一种自动妥协。 Prism比CAB更好的一个最重要的原因是你可以很容易地，我的意思很容易，推出自己的Event Aggregator并替换Prism中的那个，同时仍然使用其余的Prism。 Hooray的“组合超过继承。”你无法用CAB做到这一点。
维基：
上帝愿意和河流不起来，我将在周末结束时为“演示模式”一书提供公共Wiki。根据多人的建议，我将在公共Wiki上撰写大部分初稿。我会尽快宣布它。