Anyone ever try to use a root object (not a list) for a Crystal Report? I can use a list just fine, but I get an error trying to use the ReportClass.SetDataSource() with an editable root. (Edit: the exception says "The data source object is invalid.") Here's the code:
report.SetDataSource(transaction);
I'm assuming this is because BusinessBase doesn't implement any of the overloads for .SetDataSource() - DataSet, DataTable, IDataReader or IEnumerable, but it compiles, which seems strange.
For example, here's the code I used to see if my business object was one of those types:
Debug.WriteLine(transaction is DataSet); Debug.WriteLine(transaction is DataTable); Debug.WriteLine(transaction is IDataReader); Debug.WriteLine(transaction is System.Collections.IEnumerable);And all are false. Yet again, I don't get any compile-time errors.
Thanks,
Mike
I'm guess Crystal won't take a BusinessBase for a report data source - I may have to make a list object that just contains one child.
This is kinda odd - I don't think I've seen it before. Apologies for getting away from CSLA a bit, but it is interesting.
The intellisense for .SetDataSource is strange. When you initially choose SetDataSource, it says "void ReportDocument.SetDataSource (DataSet dataSet) + 4 overloads". So there should be five methods total. Yet it only give you four once you type in the first open parenthesis.
I can pass any object to .SetDataSource and it compiles, so there must be an overload that takes an object. Strange that the intellisense when you're picking the methods says there are 5 methods, but then later tells you there's only four.
I wonder what would cause that?
Mike
Yeah, in my case I'm printing a credit card receipt - just one row of data.
I created a list just to hold it's only child, and that works. I don't like the idea of having to create a list when I don't really need a list, though. Seems like bad design/don't need a list for my use case. But seeing as we're using Crystal and that's what Crystal needs, I'll roll with it for now.
Mike
I'd view this list as a UI artifact - not part of your business layer. It is not uncommon to have to create extra objects at the UI layer to accomodate various display requirements - and then perhaps it won't feel like so much of a hack.
Microsoft's reporting services tool takes a single object, that's true - but I had a conversation about this with a Msft person a long time ago, and as I recall, they just detect that you gave them a single object and they wrap it in a list on your behalf. Certainly thats what the BindingSource control does, because it only operates against collections...
>>I'd view this list as a UI artifact - not part of your business layer. It is not uncommon to have to create extra objects at the UI layer to accomodate various display requirements - and then perhaps it won't feel like so much of a hack.
That's pretty interesting, I hadn't thought about it like that. So now I need my child object(s) used in a "regular" list and used in a list that only allows one child. I made another list object that takes a primary key of the child.
Does that make sense or instead should I make another factory method in my original list that takes the PK? Trying to figure out which way makes more sense. On the one hand my new list exists solely for a report, so I thought it should be a different object. But it kinda seems like overkill. It's really just a filter.
Regards,
Mike
ajj3085:
... You can create a Report in VS2005 which is a client side Reporting services report, and it handles a single object just fine. I've done this to allow users to print a 'contact card' should they need to print the data.
Can you elaborate on this? i had to create a report that takes parameters, and pass the parameters in because I could NOT get the new Report to take a BusinessBase (Must implement IEnumerable).
I'd like to avoid the parameter approach.... Please tell me how you did this.
Copyright (c) Marimer LLC