I have just completed a small but interesting section of my research material for the Cologne April 2018 conference - on creating and printing reports.

It would appear that using DBF data to form nice reports is going to be quite easy, in some ways at least - if we don't work directly on the backend data files.

If we read it, and then make our data into 'in-memory' business objects, and then place these in a Collection (List<T>), we can quickly and easily create and preview a report.

Here is a example I did on the way to bed, just now :-

The Persons 'Get' method is shown below :-

The next image shows the design details - BUT - these were done automatically by the Wizard - easy :-

Finally, the bit I have been waiting to tell you we can use LINQ on the DBF data - once it has been converted to .NET types in the Properties for the Person class. Yes, you now can't escape it, LINQ with your favourite DBF file data - check this out :-

I am currently working on doing the same sort of report - BUT - with all hand code, and not using the Designer tool directly.

I may need to call on Nick's skill and expertise for this.
Hope this interests some of you guys - maybe those with DBFs ?

Since my late evening success yesterday, I have this morning moved ahead a little more with creating and showing reports using DevExpress (DX) with XSharp.

As you now know (and appreciate) this reporting can be done with DBF file data as well as SQL.

This morning I have explored the use on a WPF form of the 'DocumentPreviewControl' from the DX toolbox.

Here is the only script snippet required :-

All that needs doing in the X# code is to react to the event for the window (form) being loaded.

In the code and results display image shown below, the 'DocumentSource' property may be given a string with the filepath of a report saved as a '.PRNX' format - yes, this is a print file really, as there is an alternative format for the Report itself, these are '.repx' files.

In reality, one is formatted data output, the other a report plan, or 'blueprint', for making the report from acquired data.

Out of interest, this means we can provide users with report files which effectively have been printed, so no data is required to shown these, just the file itself - the user can't then alter or change them either.

This approach does not even require the Class definitions of business objects within the original Collection object, that used to create the report.

In the above image notice that the display shows a 'Grouped' report by City. But also that the order of each group 'set' is still in the Age order of highest to lowest, which we did with our LINQ code.

Oh! be aware that reporting like this can be done with WinForms and their related Report controls. It just so happens That I only acquired the WPF ones, because that is what I use - if I purchase these after Cologne I don't want to spend money on what I will never use ;-0)

Fingers crossed that further work and attempts move forward so smoothly