WinForm窗体传值问题<类似QQ修改头像的功能>

Question

简单说明下：主窗体<MainForm>有个头像，我点击头像弹出个人信息窗体<PeopleInfo><显示出主窗体的头像>,在个人信息窗体中，我点击修改头弹出头像窗体<SelectHandForm>这个是MainForm窗体，这个主窗体中头像的点击事件为
因为我把个人信息窗体中的PicInfo图像控件设置为public了。所以能.出来！
这个是个人信息窗体<PeopleInfo>,他的点击事件为;  这个是头像选择窗体  
我现在出现的问题就是MainForm的头像能成功的传到PeopleInfo中去，但是我想在SelectHandForm中修改头像后也能成功传到PeopleInfo去。修改PeopleInfo中的PicInfo图像控件.因为他是public的。就是这里的问题。在SelectHandForm中获取的PicInfo图像控件一直为空~WinFormQQ控件

Answer 1

在我设计程序时，通常需要先搞清楚依赖关系。如果A依赖于B，那么你设计程序时就尽量不要考虑B依赖于A，否则很快就会因为耦合的叠加而变成一团糨子。你前边描述的窗体调用关系，MainForm依赖于PeopleInfo，而后者又依赖于SelectHeadForm，那么最后这个窗体就是一个独立的、为各种宿主程序提供服务的工具窗体，它不应该想当然地去假设什么“Picinfo”图片框的存在。它应该自己定义一个属性，例如public Image SelectedImage{get;set;}然后这个窗体定义一个业务事件，例如public event EventHandler ImageChanged;
而你的button1_click中的代码，作为这个SelectHeadForm的宿主，它才需要去监听这个事件，例如写var shf= new SelectHeadForm();
shf.ImageChanged += (s,arg) => 
    {
        this.PicInfo.Image= shf.SelectedImage;
    };
shf.Show();总之，设计程序要首先搞清楚“职责”。是PeopleInfo该去获取图片的业务，就不要让SelectHeadForm去推送。

Answer 2

在我设计程序时，通常需要先搞清楚依赖关系。如果A依赖于B  -->  在设计程序时，通常需要先搞清楚依赖关系。如果A依赖于B事实上，谁依赖于谁，这取决于设计者的个人爱好(其实跟最初对需求的理解、第一感觉有关系）。但是关键是，设计者一旦决定了一种依赖方向，那么对于反向的依赖，就应该坚持“依赖倒置”的原则。这里，一旦决定了 SelectHeadForm 是一个独立的工具窗体，那么也就顺理成章地决定了，选择图片的结果——SelectedImage属性——仅仅在它自己的接口上来定义。然后它抛出一个事件通知，让任何一个监听这个事件的宿主调用程序能够知道自己已经把SelectedImage属性给设置好了！站在设计的角度，我们绝不去让 SelectHeadForm 去想当然地纠结什么“PeopleInfo里边有个PicInfo属性”这种问题。你会发现，进行程序设计中保持单向依赖，才能避免“一团糨子”式的组件应用结果。但是你要注意的是，谁依赖于谁，并没有一定之规。关键时一旦决定了，就不要变来变去地。

Answer 3

http://download.csdn.net/detail/kllxyu/5598479  我的资源里面有 winfrom窗体传值

Answer 4

多谢caozhy sp1234 两位的细心回答。我从caozhy 说的中得到灵感用构造函数传值。又从sp1234 说的中知道了窗体的依赖关系，可能我就出现了相互依赖的情况。本想用两位都使用了的事件来做，但是我对事件理解不行。还得去上网学习，因此我就用了比较土的方法吧。--在PeopleInfo窗体打开SelectHeadForm窗体的时候，会实例化SelectHeadForm窗体对象，我就写了个SelectHeadForm窗体的构造函数，在PeopleInfo实例化SelectHeadForm的时候将PeopleInfo这个窗体传过去< SelectHeadForm shf = new SelectHeadForm(this);>SelectHeadForm的构造函数< public SelectHeadForm(PeopleInfo pp){InitializeComponent();p = pp;}; :p是我在SelectHeadForm窗体中创建的PeopleInfo实例>.这样做效果是实现了，但是这样会有什么不好的方面吗？比如安全方面？还是性能方面？还是没有影响呢？