Rick,

What was the reason for this? Was is reliability, speed or "simplify distribution and compilation?"

Thanks, Bruce

Bruce,

I've always hated VCX classes because they are so unwieldy.

Hard to edit requiring modi class, no easy way to compare files with something like Beyond Compare (unless you build compare files which is a pain), source control problems (again compare files required). Can't edit in an external editor (something I'm doing more and more of). PRGs are also easier to load automatically and you can self-loading dependencies (ie. DO wwHttp then inside do SET PROCEDURE/CLASSLIB TO all the things you need)...

All of this makes it easier to work with PRG files than VCXs during development and maintenance.

For Web Connection in particular nothing needs to be a VCX except for the few visual classes that make up the server form and related controls and that's all that's left as a VCX now. And those files very, very rarely change.

+++ Rick ---

Rick - I never did this, but if people had built there BO class in a VCX, based off of classes in wwBusiness.vcx, won't this break their VCXs? It's my understanding that VCX libs cannot be based on PRG-based classes, only other VCXs.

Am I wrong about this? If not, then how are you advising your users to update to Ver 7? and still get their VCXs to work?

Right - at that point you have two choices:

• turn the classes into prgs and fix the base classes

• continue to use the old vcx classes from the old files folder

Converting classes can be pretty easy using the class browsers export to prgs and then renaming which can be a search and replace operation.

Most of my old bis objects started as vcxs and the conversion is easy. More recent classes I had already used prg classes subclassed from the vcxs. To me that’s so much easier workflow than dealing with the class designer’s clusterfuck 😃

But if you have a lot of old code it might be easier to stick with the old classes...

Going forward though using the new classes is recommended.