一个页面有两个UserControl分别为UC_A和UC_BUC_A里面有个radioboxlist,单击上面任何一个radio都会触发一个自己定义的事件,该事件由UC_B响应,UC_B根据事件传递过来的值,动态生成checkboxlist控件。现在发现,在点击radio之后,第一次生成的checkboxlist无法得到选中的checkbox。在页面postback一次之后,可以选中。
所以请问一下,这种两个控件之间传递值的方法是否可行?

解决方案 »

  1.   

    看不懂UC_A的事件这么由UC_B响应?
      

  2.   

    UC_A和UC_B共享一个object,该object有事件,UC_B对该事件注册。
      

  3.   

    动态生成checkboxlist控件
    ========
    ASP.NET 动态构造 UI 很是恼火啊, 可别想当然是 WinForm 哦
      

  4.   

    UC_A和UC_B共享一个object,该object有事件,UC_B对该事件注册。
    ——————————————————————————————————————————
    不懂什么意思。“共享”的前提是以一种隐喻的方式相互牵制地设计这两个控件。如果这两个控件是低耦合地独立设计的,各自执行各自的职责,有各自独立的设计任务,那么他们“共享一个object”就是一种匪夷所思的低级设计错误。我们举个例子:假设一个页面上有一个“编辑商品信息”控件,旁边一个“显示商品关税”控件,当用户在商品信息里一旦更新了商品编号,就会触发一个“商品编号更新”的事件,页面设计要求关税与最新的商品相符。这里,职责是页面定义的,不是两个控件自己定义的。页面注册第一个控件的“商品编号更新”事件,然后调用第二个控件的接口方法(设置属性来)刷新显示。两个控件的设计是独立的,它是服务,如果有事可以事件通知,而不是搞什么与别的某个控件共享什么对象。
      

  5.   

    这样设计之后,就跟所有asp.net内置控件的控制方法一模一样了。如果你点击一个RadioButton,当然触发一个事件,然后你在这个事件中根据这个RadionButton的Checked值来更新其它控件。一个程序员在一个程序中千百次地这样控制asp.net控件,为什么自己开发的用户控件就不能简单直接地来这样呢?大概很多人觉得这些东西不够时髦。有时候学太多“模式、标准”反而有害。如果深入掌握原理,那些为入门者准备的模型就只应该做参考实例,而不是盲目套用。