>>>>Is there a specific reason why you do most of your reports to Excel nowadays? Is it a demand by your customer(s) or is there another reason?
>>>
>>>I must explain, first of all, that this is for internal use in the company. So, we can safely assume everyone has Excel installed - which is not always a safe assumption for commercial software.
>>>
>>>We found that doing reports in Excel gives users more flexibility, since most users already have some basic knowledge of Excel, and can change data sorting, do autofilters, add formulae, etc. This is much more difficult to achive with the built-in VFP reports. (Another note: I did not compare several other tools that are popular among UT users, for example, Crystal Reports. Specifically in the case of CR, the company is quite reluctant to do any additional expenses. Now don't you explain the advantages of those expenses to me, since I didn't take that decision...)
>>>
>>>Also, Excel provides some options for the programmer that are difficult to achieve with the built-in report designer. For example, try to make a report with a variable number of columns - for example, more or less columns, depending on the number of weeks the user wants to see!
>>
>>Is there any layout in the reports, or is it essentially filling cells A1:X100 with headers and B1:X100 with values? Do you fill template sheets with additional values? Do you ask Excel to print a neat report or need users start up Excel for that job?
>
>I heartily invite you to take a look at the sample!

And I accepted the invitation. :)

Your explanations below made the concept clear to me. It's an interesting usage of Excel (and Notepad and the browser). I guess that with some additional knowledge of Excel the layout can be completely controlled and Excel functions can be used to make additional computations there. The sky is the limit.

I notice that a copy of Excel is started and that users are consequently in control of the sheets. If they want to print, they'll have to choose File > Print. But I also imagine that it's an option to let VFP send the print instruction to Excel.

One drawback when compared to a report designer is that the developer has no GUI when designing. While I no longer use Views, but instead suffice to code all queries, I still prefer the GUI when designing reports. But I'd agree if it would be noted that this is not an essential requirement when designing a report. Rather, it's a luxury.

Good work Hilmar! The idea is inspiring.


>No templates; no action required by the user. Data is filled up in Excel, but several methods make the Automation task easier. See below.
>
>You subclass the reporting class, and then fill out several methods, the most important of which are:
>
>

.Select() - data selection goes here.
>

.Detail() - invoked once for every record.
>

.ReportHeader(), .ReportFooter() - invoked once for the report
>

.PageHeader() - once per page; basically only useful for the text report version.
>

.Init() - Here you define some important properties, including the array that defines the data grouping.
>

.GroupHeader(), .GroupFooter() - run once at the beginning of each data group.
>
>Most output is produced with .Print() and .PrintLine() methods; although in the Excel report, the programmer can select any cell. .Print() will advance to the next column, .PrintLine() to the next row.
>
>Example:
>

>* .Detail() method
>This.PrintLine(Field1, Field2, Field3)
>

>
>This will advance a row, and fill the first three columns with the values specified.

Groet,
Peter de Valença

Constructive frustration is the breeding ground of genius.
If there’s no willingness to moderate for the sake of good debate, then I have no willingness to debate at all.
Let's develop superb standards that will end the holy wars.
"There are three types of people: Alphas and Betas", said the beta decisively.
If you find this message rude or offensive or stupid, please take a step away from the keyboard and try to think calmly about an eventual a possible alternative explanation of my message.