Feature request for Fields

[sitefinitysteve]

I use OA as my datasource quite a bit and thus use NeedsDataSource about 99% of the time.  So I lose all designtime access to show me the Fields Available (the OA DS doesn't always fill the need)

Could you provide some way for me to expose the fields?  Perhaps override or implement an interface somewhere in the code where the designer would get me back those field names that I manually define?

Steve

[Marcus Kellermann]

I second that.  Having an interface we could implement for a better design time experience would be a huge productivity increase.

[sitefinitysteve]

(sidenote)

I keep having to go back to the code, do a .First() on the collection to see what properties are available

I guess I could also compile the list and put them in the summary to copy\paste...but I still want to see them in the designer instead of constantly copy\pasting.  Especially since the combo boxes in some of the popup dialogs irritatingly don't accept Left-Right keystrokes (causes the text inside to commit)

[Svetoslav]

Hi guys,

The only way for the report designer to show you any data source related information (incl. data source schema) is to have a valid data source available at design time. As far as the Visual Studio designer is concerned a valid data source means:

• a data source object that is instantiated and initialized in the InitializeComponent() method of the designed object class -- this is the only part of the class that VS designer respects;
• the data source object should be be operational at design time; this means that VS (through the report designer) should be able to use this object and even instantiate it correctly. The tricky part here is that these objects become part of the VS application (devenv.exe) and not your application (your application from the VS' point of view is just a couple of work items - projects and files and not an executable).

Having the above in mind we have designed and developed a set of data source components that should overcome most of the design time issues while giving you the freedom to connect to a wide variety of data sources incl. databases, OR/mappers, Analysis Services' Cubes, etc. For more information please see Data Source Components.
Back to your questions. Having valid data sources attached to the data items at design time is the only way to have any information about the data schema; the interface you are talking about already exists and it is called Telerik.Reporting.DataSource class. Generally speaking the existing data source objects cover most of the scenarios; in the rare cases when they do not work you can always mock your data just to enable the report designer to show any data schema.

If you still experience any troubles connecting data to your reports, we will appreciate if you can share with us your scenarios for our examination and then we can give you any advice on how to proceed or even improve the things on our end.

All the best,
Svetoslav
the Telerik team

[sitefinitysteve]

Hey Svetoslav
"Having the above in mind we have designed and developed a set of data source components that should overcome most of the design time issues while giving you the freedom to connect to a wide variety of data sources incl. databases,"

Well in an OpenAccess environment it really doesn't cover anything but BASIC scenarios as I don't believe you can leverage the navigation properties of a model using your OpenAccess DS (I believe this is a limitation of OA, not you guys).  So I can't bind a report expression to =Fields.AspnetUser.Username....I'd have to open NeedsDataSource and flatten that object out so the username is on the root level, OR create a database view for the report to link to OA.

So then from your message I guess what I'm asking for is a DUMMY datasource drag\drop component which I can just specify the fields I want the designer to show, then it just goes away during Render\Processing and lets the NeedsDataSource be primary.

Steve