>Fabio,
>
>>Here the VFPT has a negatively surprised to me.
>>Where it is the ReportFRXFile property R/W that contains the reference to the frx file?
>
>What are you trying to accomplish, specifically? Do you want to substitute a different version of the FRX at runtime, or what? What good would it be to have a R/W property ReportFRXFile that could be changed during the report run? The FRX info is already read into the internal structures after LoadReport, and you can do whatever you want in LoadReport to point to a different version of the FRX if you want (see help file entry for LoadReport for a specific example of this).

David,

CommandClauses fix the ReportFRXFile issue.

But the LoadReport example it does not appeal to to me at all.
Apply into this case:

- LoadReport rename the RealFRX to tempFRX
- Application crash ( nobody can put the hand on the fire and say that it cannot happen )
- At this point the Application have lost the RealFRX!!!

If the crash happen between the two RENAME in UnloadReport
you have merged the userFRX with RealFRX.

My design choice, THIS.CommandClauses.FILE or another property RW into LoadReport:
<pre>
copy GetFile("frx") report into a tempFRX ( same for frt )
* set the source report file
THIS.CommandClauses.FILE = THIS.tempFRX

This is immune from crash why it does not leave status into the hard disk.

Of course, the workaround is immediate, but RW is more simple.

>
>>I have given one read without to read.
>>I would prefer to read something written from who has thought and designed this outline of operations; but this happens very rarely.
>
>As far as I have been able to determine, the very extensive help file entries for the VFP9 report system were written by Lisa and Colin Nicholls, who designed how the report system works. So, in this case, you do have a rare occurrence, and there is some very in-depth info there -- much more than for other parts of the product, in my opinion.

I agree, and i see it.

>
>>Normally I see articles written from third persons,
>>than based on what they have understood,
>>they interpret the thought of who has made really the things.
>>
>>I write this why you are the Editor of Fox Talk 2.0.
>>It is not a controversy, is only one my preference.
>>Any comments ?
>
>In this case you have the best of both worlds -- help file written by the designers, and articles, white papers (and book chapters) written by people who have worked with the new report system for over a year during beta. We plan to run extensive articles over the next year in FoxTalk 2.0 about the report system (Doug's articles for Feb, March, and April are all on this topic, and Walter Nicholls showed some cool Report stuff in his previous articles on the GDIPLUS FFC class.)
>
>After you have figured out some really cool ways to use/enhance the ReportListeners, I would be happy to hear your proposals for articles you would like to write. :-)

If i found a good base point, i send to you it.

>
>I did raise the idea of articles with the designers, but they were very involved at the time with creating the help system including sample code and getting the final finishing touches into the product. The end result of their efforts is that, if you wanted a series of articles or a book from the report system designers, you already have it in the help file.

Ill-fatedly my English does not allow me to propose something of interesting like writer.

Thank for the courtesy David.

Fabio