Wiki Home

VCXvs SCX


Namespace: WIN_COM_API
A place to discuss the advantages and disadvantages of VCX vs SCX-based forms
Here is a brief summary of the principal differences/advantages/disadvantages of .SCX-based vs .VCX-based forms. We believe there is no clear-cut winner here, although in general we prefer .SCX-based forms. -- Drew Speedie

This comparison is a very good way to find ways of accomplishing things in VCX-based forms that are easy in SCX-based forms, or the other way around, when trying to solve a problem. - ?wgcs

What I would recommend in most cases is to create the form as a VCX class, to take advantages of classes, and then subclass it without any further modifications into a SCX form to avoid the problems that a VCX form can cause and to take advantages of the SCX form. -- Christof Wollenhaupt
But if you create the form as a VCX, then you lose the drag/drop from the DE, which is one of the biggest advantages of an SCX. -- Ed Leafe
The only time I'd need that feature is when I want to create a grid that doesn't contain all fields. Otherwise dragging from the project manager works just fine. And what prevents you from using a temporary SCX to place all tables in there and drag them on your VCX form? I really haven't used the native data environment for a long time now. -- Christof Wollenhaupt

VCX-based forms advantages:
  • Easily subclassed.
  • Many forms can be contained in one .VCX/.VCT file (disadvantage for team development).
  • Protected and Hidden properties and methods are supported
  • Can substitute a user-defined (.PRG coded) Data Environment subclass at runtime or use a visual class to provide the data environment.
  • Subclasses can inherit DEs added as above.
  • Complete control over opening tables/views.
  • Syntax used to create VCX form is consistent with the rest of VFP.
    VCX-based forms disadvantages:
  • Cannot use the native visual Data Environment.
  • Since the native visual Data Environment cannot be used, populating ControlSources and RecordSources must be done manually. Or you drag and drop fields from the Data tab of the project manager or the database container. This can be remedied by writing or purchasing wizards and/or builders. -- Mike Feltman
  • More difficult to run/test, takes 2 or 3 commands∑ No simple, direct way to RETURN a value from a modal form. Unless you have wrapper methods or functions to do this. -- Mike Feltman
  • VFP Form Wizard not available (but we donít recommend using the native wizards anyway...).
  • If many forms are contained in one .VCX/.VCT, team development is more difficult because more than one developer can't easily be working with different forms stored in the same .VCX. This isn't really a disadvantage of a VCX based form, it's a disadvantage of deciding to store multiple form classes in a single .VCX -- Mike Feltman
  • Has more bugs than a SCX form. For example, a complex VCX form might suddenly start releasing itself during the Init. But a form based on that VCX would run fine? I'd think you'd have problems in both cases. -- Ed Leafe No, the problem has been solved by subclassing the VCX into a SCX, because internally VFP treats a SCX form widely differently. During the development in the last year we have found many problems with VCX based form that disappeared when we subclassed them into a SCX. -- Christof Wollenhaupt
  • If a controlsource has got a typo, all you get is a "Cannot create object" error message, whereas the SCX form tells you which field is wrong. Unless your base classes handle this situation. -- Mike Feltman

    SCX-based forms advantages:
  • Use the native visual Data Environment.
  • If the Data Environment is used, populate ControlSources and RecordSources via drop-down.
  • Easy to run/test, with one command or via the Run option on the Standard toolbar.
  • Simple, direct way to RETURN a value from a modal form.
  • Can substitute a user-defined (.PRG coded) Data Environment subclass at runtime.
  • Form Wizard available (although we donít recommend using the native wizards).
  • Team development is less of a problem because each form is always stored in its own .SCX/.SCT.
    SCX-based forms disadvantages:
  • A little more difficult to subclass; intended for use at the instance level.
  • Only one form per .SCX/.SCT file (lots of individual files), but could be an advantage in team development projects (see above).
  • Protected and Hidden properties and methods are not supported.
  • No real control over opening tables/views in the Data Environment (although you can do that in the form.load() if you want Ė you'll lose the benefits of using the native Data Environment, while still having the other .SCX-based form benefits).
  • Inconsistent; uses a different syntax for creation than every other object in VFP.
  • Cannot edit a form if any other developer is running that form.
  • The VFP data environment, especially when used directly in a form, is really only useful in Monolithic Applications.
  • The built in form data environment and all of its member objects, such as cursors, are based on the VFP base classes. When the native DE is used the only way to customize it is to modify every instance of it in every application. Hopefully this will change someday. Unforseen needs to enhance the DE or cursors can introduce a serious maintenance problem. -- Mike Feltman
    Visual Max Frame Professional supports .SCX-based forms, .VCX-based forms, or any combination thereof. The decision of which to use in what situations is entirely up to you, the developer.

    The sample VM application uses predominantly .SCX-based forms because:
  • there is nothing "wrong" or "inferior" about .SCX-based forms,
  • experienced Fox2x developers new to VFP usually have an easier time getting started with .SCX-based forms created in the Form Designer than .VCX-based forms created in the Class Designer,
  • .SCX-based forms offer the advantage to newer VFP developers of the visual Data Environment instead of the extra work of manual setup in the form.load() or extra complication of hand-coded DataEnvironment/Cursor/Relation classes/objects
    This page has really elucidated the issues on this question very clearly. The question really comes down to, "Which way feels better?" There can be very strong arguments mounted for either approach, but none of the arguments ever makes the other one a "wrong way" to do things. The only caution to keep in mind is, "Consistency makes maintenance easier." That is, choose one or the other and stick with it unless there is an overpowering reason to use the other method.

    If you always DO FORM with an scx, or you always Create Object() from a VCX your code will be consistent and your maintenance efforts will be easier. -- Jim BoothOffsite link to http://www.jamesbooth.com
    I've taken a compromise position on the SCX vs VCX form question. When I first design a form, I will develop it as an SCX. When the form is ready for prime-time, I will save it as a class, get rid of the code and objects from the SCX and hack the SCX so it uses the form class I just created. I get the benefits of being able to subclass a form, as the form is its own class. Also, I get the benefits of the visual data environment. I think a hybrid approach is really an excellent way to consider. -- William OConnor
    Refactored by: Jim BoothOffsite link to http://www.jamesbooth.com
    Contributors: Drew Speedie (by permission, with thanks, and added by Steven Black), Christof Wollenhaupt, Mike Feltman, Jim BoothOffsite link to http://www.jamesbooth.com
, William OConnor
    Category Learning VFP Category Class Design
  • ( Topic last updated: 2002.04.03 12:46:15 PM )