| |
ActiveReports for .NET 3.0 Support
Started by Nathan Baulch at 02-21-2007 6:51 AM. Topic has 1 replies.
  
|
|
Sort Posts:
|
|
|
|
 02-21-2007, 6:51 AM
|
Nathan Baulch
Joined on 02-13-2006
Posts 21
|
Bug in ListDataSource (still!)...
|
|
|
|
|
I get the following exception when running a report which is bound against a list of business objects:
System.ArgumentException was unhandled
Message="Invalid value.\r\nParameter name: expression"
Source="ActiveReports3"
ParamName="expression"
StackTrace:
at -2ch.-0fa2.-ac03(Object expression, String style, CultureInfo culture)
at DataDynamics.ActiveReports.TextBox.set_Value(Object value)
at DataDynamics.ActiveReports.TextBox.-ddde(Object val)
at DataDynamics.ActiveReports.-bf0.-cbb(Section section)
at DataDynamics.ActiveReports.-c3ae.-1efd(Object parentReport, Single left, Single top, Single right, Single bottom)
at DataDynamics.ActiveReports.ActiveReport3.-13b(Boolean bDelayedInit)
at DataDynamics.ActiveReports.ActiveReport3.Run(Boolean syncDocument)
at DataDynamics.ActiveReports.ActiveReport3.Run()
This feels a lot like the ListDataSource bug that I reported in v2 here: http://www.datadynamics.com/forums/89503/ShowPost.aspx
On closer inspection, it looks like this bug still hasn't been fixed since Type.GetProperties is still being called in three different places in this class (in the FillSchema, GetTargetObject and GetValue methods). As I said in my original post, the GetProperties method in .net v2 is no longer guaranteed to return the PropertyInfo items in the same order each time it's called.
This bug can be very easily fixed by introducing a class level field of type PropertyInfo[] which is assigned the first time GetProperties is called and used instead of GetProperties for the remainder of the object's life. I'm more than happy to send a replacement class with this change if you like.
This leads me to my next PITA. I thought that I could simply write my own data source implementing IDataReader that is basically the same as ListDataSource but with this bug fixed. However it turns out that the DataLayer.GetFieldValue method has special case for ListDataSource whereby it calls an overload of the ListDataSource.GetValue method to add support for traversing the business object graph with dot notation (eg, "Company.Address.State"). I guess this is necessary since it would be unreasonable to expect IDataReader.GetSchemaTable to return a DataTable containing every possible combination of object traversals (actually it would be impossible if you consider parent-child relationships where a type references itself).
So I guess what I would really like to see is an extensible, object oriented approach to report data sources whereby the OleDB/SqlDB/XML/List data source objects implement a common interface or extend a common base class. The rest of active reports would only use this interface/base class with no more special cases, thus enabling us developers to write our own data sources. Again, I'm more than happy to give some suggestions in this area.
Cheers,
Nathan
|
|
|
|
|
Report
|
|
|
|
|
03-04-2007, 6:49 PM
|
Nathan Baulch
Joined on 02-13-2006
Posts 21
|
Re: Bug in ListDataSource (still!)...
|
|
|
|
|
|
|
|
|
GrapeCity » Product Support » ActiveReports f... » Bug in ListDataSource (still!)...
|
|
|
|
|