Not really. I can have a single .prg called thefunc.prg. I can DO THEFUNC or I can llSuccess = THEFUNC(). I don't have to SET PROCEDURE TO THEFUNC first.

I always have to have SET CLASSLIB TO to access that single class. Further, if that class is subclassed, VFP must be doing a SET CLASSLIB TO the parent class. There is also the issue of opening different classlibs with aliases and basically having to manage the entire set of opened classlibs.

With a classlib-less approach I imagine I could have a class in a DBF or txt file and simply CreateObject("myclass") to use it. Further, that should be the first thing VFP tries to open. Once all of these class files are compiled into an exe, the performance should be very good indeed, since there would be a lot less SET CLASSLIBing going on.

>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?
>>>>>>