I appreciate your input. As far as having a class file, a library of one class is sort of like a class file, isn't? <g>.

>It's the degree of packaging that bothers me. VFP doesn't put everything in one massive file. It has separate dbfs, cdxs, fpts dbcs, frx, frt, scx etc. I believe the first choice should be separate files. I still wish there was a class file in addition to a class library file. Putting all your eggs in one basket is ill-advised.
>
>I'm not disputing your freedom to package things. I'm just pointing out that it isn't always right.
>
>>Yes, it is possible that .DBF would get corrupted. Then the customer would download a new one from the web. I am not arguing with you, I see your point. So I guess my personal preference is to have one file and maybe a chance of a corruption. But by the same token, if VFP tables are so prone to corruption why do we keep a valuable data in them? The reports is something that can be easily replaced, but if the data is lost, it is more serious problem. But this is a topic for a different thread, I guess.
>>
>>>And if the DBF containing the reports gets corrupted? You could end up producing an invalid frx. Is this personal preference worth the potential crash?
>>>
>>>>Hi Mike,
>>>>
>>>>I don't see any technical problem with placing reports in their own folder. As I was saying, I was just concerned that one of the file could get corrupted and that it will "look" better (IMO) to have all report names hidden from the user. Probably just a matter of personal preference.
>>>>
>>>>>Hi Dmitry
>>>>>
>>>>>I seem to be relatively alone in my belief that things are being "packaged" too often and for too little reason. If you package your reports in a DBF you then have to find a way to update individual reports in this DBF or you have to ship the entire DBF everytime you change one report.
>>>>>
>>>>>Why not put the reports in their own folder?
>>>>>