>Well, I'm not saying I wouldn't use it, it could be a big plus. But it may be extremely difficult, else they might well've done it by now in vfp...what you're talking about reminds me a lot of the old .spr files, you could edit "object" code, then just build the spx and voila, the runtime is updated. Of course, the original screen files weren't updated, so that wasn't all that helpful :)
>
>One thing I do as you're saying is with views. I very seldom use the designer, just make a prg from gendbc code for every view and then update views progammatically...and you can do that with an entire database, of course...


Right. Sometimes it's just easier if you can look at a program file. It wouldn't be very difficult to pull all of the procedures from a VCX or SCX file and then edit them and push them back into the appropriate file, but it isn't very automated. You would have to make sure that you always remembered to put it back when you were done, which could lead to problems. I guess it is a fundamental design difference between something like Delphi and VFP. Delphi just stores everything in a text file and parses it, while VFP stores it in a table.

I guess the problem is preserving all of the advantages of having a GUI design interface with the ease of use of program file access. I guess most people just don't care, but at our business we have about a dozen versions of the same package for different vertical markets. We frequently merge code changes between packages or for customized versions of the software, and the easiest way to do that is to pull up the code from both in an editor and then just work through it and merge. Oddly enough, the best editors for this are DOS editors because they are the easiest to see differences in because you can quickly toggle screens.

Anyway, that's neither here nor there. Point is, program file level access would be very nice.