Solution Log | Antonio David - NVNCBL » visual studio

Chart Control Dynamic Data Labels

Antonio — Tue, 11 Aug 2009 21:32:35 +0000

When using a chart control to plot data from a stored procedure (or any query for that matter), the stored procedure needs to return series’ in columns. Data to be plotted has to be in numeric form. How, then, can we label the series? Perhaps one would think to add a row at the top of the result set to contain the labels. But that won’t work because the column data types are numeric and the labels are most likely strings.

Fix:

Have the stored procedure return the data labels in separate columns. For example, you have a table:

year	best	average	worst
2009	5	4	3
2008	7	5	3
2007	6	5	4
2006	15	3	2
2005	6	1	0

… and in the resulting graph, you want series “best” and “worst” to be labeled something different. Simply modify the result to look like:

year	best	average	worst	best_label	worst_label
2009	5	4	3	Region 1	Region 4
2008	7	5	3	Region 1	Region 4
2007	6	5	4	Region 1	Region 4
2006	15	3	2	Region 1	Region 4
2005	6	1	0	Region 1	Region 4

… and from there, set the label to the value of the new label columns. It admittedly isn’t the most conceptually elegant solution to the problem, but if you’re pressed for time and desperately in need of a quick fix, why not go for it?

Plotting a Line Graph using Chart control

Antonio — Tue, 11 Aug 2009 18:23:54 +0000

If you’re having trouble plotting series of data using the Chart Control, make sure that the data coming in is plottable.

That means using a numerical data type. Duh!

When Wizards Get in the Way

Antonio — Sun, 14 Jun 2009 17:57:07 +0000

Many of Microsoft’s development products, when given an SQL query, will try to perform all sorts of analysis and breakdowns on the query — usually in an attempt to visualize what’s going on. When the queries become too complex (as the tend to be), they just can’t be parsed and visualized. Furthermore, when the successful parsing of a query is critical to one of their “wizards”, your report creation process can be brought to a standstill.

Queries that have a few levels of subquery nesting, or that have UNIONs, for example, will sometimes break parsing.

So, if you don’t want your development tools (such as Visual Studio) to get in the way of completing a report wizard, put your SQL query in a stored procedure. This way, your tools won’t be concerned with the nitty gritty details of your query. You can still pass @variables to the query, and you can make changes to the query without stepping into your designer’s .rdlc files.