I spent an hour with Kirsten this morning and we got her report working. The problem, or misunderstanding, or minor confusion was caused by what I sometimes call "the wizard trap" or the "drag and drop trap". I was also confused by these same issues when .NET first came out and I think they are still hindering progress of a lot of newbie .NET developers.
The authors of many Framework components seem to have gone to a lot of effort to create clever behaviour, such as when you drag a database table into the designer to make an XSD or you drag a BindingSource class onto a Form. These sorts of actions create all sorts of magical things like config files with connection strings, app property files, DataAdapters, default property values, etc. These things are fabulous for demos where you can whip-up a working app with almost no code. This is still a popular way of making Silverlight demos with Sketchflow and RIA services. However, sadly, I think that these miraculous wizard behaviours are an impediment to writing scalable nicely structured apps. This morning was an example, as the stuff created by dragging reports and data sources into forms just created clutter and ambiguity about the way to do things. We deleted all of the wizard generated classes and properties and used classic VB.NET code with ADO to run a sproc and feed the results and parameters into a report view control. It's about 20 lines of code, but it's clear, and most importantly easy to refactor into a reusable DLL which was the end result Kirsten wanted. Wizards should stay in Middle Earth. Greg
_______________________________________________ ozdotnet mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozdotnet
