Question

I have a _Click event that is firing when a chart is clicked on. In this event I immediately cast the sender to type Chart. I often follow this paradigm but feel icky each time that I do.

In this particular instance I am also immediately running out to find a corresponding UpdatePanel so I can add a dynamically rendered GridView to it. The Chart and UpdatePanel are cobbled together by having similar IDs. Both the chart and updatepanel are dynamically created at runtime.

I am wondering if there is a better/preferred way to implement this sort of behavior.

protected void Chart_Click(object sender, ImageMapEventArgs e) {     Chart chart = (Chart)sender;     UpdatePanel up = (UpdatePanel)chart.Parent.FindControl(chart.ID + 'UP');      GridView gv = new GridView();     Dictionary<string, string> displayFields =         new Dictionary<string, string>();      // add data to displayFields by using the ImageMapEventArgs.PostBackValue     // to create data for dictionary ...      gv.DataSource = displayFields;     gv.DataBind();     up.ContentTemplateContainer.Controls.Add(gv); } 

Answer 1

I’m not sure what else can be done about casting sender to a chart (other than using as), but there are many ways to deal with the associated controls problem.

• Add a property to the Chart called ‘LinkedPanel’ and assign your update panel to it

  You’ll see a similar pattern used in a notification icon, where you associate it with a context menu)

  I think this is particularly nice, because when it’s done right you can just assign the linked control in the form designer. (Of course it won’t help with your dynamically generated controls)

• Combine both controls into a single UserControl (if the controls always show right next to each other, this might be the right thing to do)

• Create an object that knows about both controls, and have it handle the events that they raise

I agree that depending on the name just feels wrong; I’d be too embarassed/nervous to use it in production code :-/ (If you’re the only developer, then I guess it’s up to you…)

Using these other approaches makes it less likely that an ‘innocent change’ made by another developer is going to start causing unexpected exceptions.