Wiki Home

Things To Reconsider


Namespace: VFP
I've recently come to notice that some things I have always thought of as necessary parts of any medium to large-scale VFP project may, in fact be more trouble than they are worth. Not to say there is no use case for these, but I've found a careful reassessment of the cost/benefit of these tools helpful, in particular when planning web-based projects.

I wonder what you would add/subtract to/from this list?
Projects (PJX files)
Sometimes add more overhead than they are worth. There is tremendous freedom in a set of free .prg files.
I truly don't see anything wrong with project files. Every large development IDE has some means of gathering all the files together. -- ?df
I sure like being able to get to all the parts of the project with one click!
Don't you need a PJX to make an EXE or DLL anyway?
I cannot imagine managing any notable amount of VFP development that goes into production and has at least a few years life span without using a project. Expecially since component-based development seems to be leading us towards the bigger picture of an application being comprised of more parts and pieces than they were a few years ago.
All good points. Perhaps I am painting with too broad a brush here. Recently, my work has been pretty much exclusively web-based projects. I used to always use PJXs for these, but have recently been introduced to the idea of leaving everything loose in well-organized directories. Updates consist of uploading the new .prg's , and restarting the (non-COM) server. Done. Obviously, for projects involving visual components and/or .dlls some sort of BUILD PROJECT has to take place.

Database Containers (DBC 's)
Some nice features, but in truth, VFP falls far short in a number of areas here. The recent simplifying advances in MS SQL7 (or alternatively MSDE) might make them a better choice if you really need those features. If you don't, consider free VFP tables.
Being able to have long field names that tell me what I'm working with is worth the price! When I read other people's code, like in a newsgroup post, and they have cryptic 8 or 10-letter names, I realize why I like long names so much!
I dont think the problem is in the DBC implementation itself, but rather the problem is your choice of data store. If you dont need the added security and a more robust database backend like SQL Server or others, so therefore your decision to use a VFP backend is justified, I see absolutely no reason NOT to use a dbc.
I like long field names too...until I have to move a table (perhaps with the data) from one DBC to another < g >. (Maybe this is easier now, but I recall writing a tool to do it properly in VFP5). My point is, that blindly creating a dbc for every project might be introducing an unnecessary level of complexity. Having a well defined set of Data Objects supporting the Business Objects can go a long way in integrating the data source apart from a DBC. Also, I feel the requirements window for which a pure VFP backend is the optimal long-term choice is shrinking with the advance of really robust and (relatively) easy to use backends like SQL Server.
Ummm - It's not easy to move a table to another database with drag and drop, but if you know how to type < bg > you can easily COPY TO MyFile DATABASE MyDatabase. If the table needs to travel you can create a database named Briefcase and bring it home in that!
Well, what do you know! Was that possible in VFP5? Anyway, point well taken. I guess I am just going through a period overzealous ?KISS.
Unfortunately, COPY TO MyFile DATABASE MyDatabase does not include any field or table property settings, and the database must already exist. You're probably still looking at some Alter Table commands and a slew of dbsetprop()'s to properly duplicate or transfer a table from one DBC to another. See note1 below.
What do you think about the following. Use the DBC as a Table and do some nice COPY? All settings are in there. (O.K. it's not pure DBMS but it's Microsoft)

11/29/2007
note1
Wouldn't adding "with production" to the end of "COPY TO MyFile DATABASE MyDatabase " fix the issue?

Visual Class Libraries (VCX files)
See PRGvs VCX
I think this is really the only valid point on the list worth reconsidering. The hassle with VCX's living an extended life in Source Control and the frequent corruption problems stemming from that is more than enough justification IMO to use prg's over vcx's. Especially in the business tier.
I've never had any problem with VCX's getting corrupted. I work with medium to large size VCXs containing classes that change very frequently (due to client demand and regulatory issues) and I have found that the ability to
  • isolate one method to a window
  • or to see individual methods in different windows at once
  • have parameters auto-inserted even for custom methods
  • see PEMs at a glance in the PEM window
more than makes up for any other shortcomings (like not being able to #Include for a whole set of classes.
PRGs will run quicker - so, before you compile your DLL - dump the code from the VCX into a PRG and use that instead. That's what Project Hooks are for :)

I would like to add two other topics to this list, I've been wondering for a while. Fernando Alvares

OCX vs Direct Dll Calls
The first topic is regarding to the use of controls contained in OCX files. About two years ago I started using Dyna ZIP wich I found a very good product, that helps me a lot. At the beginning I used the OCX interface, but after some problems (like application deploiment) I shifted to the Dll call interface (DZ_Eazy) and my problems were gone. Other problems came when I started using the controls contained in other OCX files (treeview, listview ...). The same: deploiment, diferent Windows versions etc. In this last example, of course, we don't have the option of a direct Dll call, but the problem still exists. Are OCX a source of trouble ? Or, perhaps, some don't have enough experience to deal with the OCX stuff ? What I am saying is not to reconsider the OCX usage, but I think that some aspects of it could be improved.

Debugging Techniques vs Debugging Tools
The second topic is related to the use of the debugger (this one I think is a bit more controversial). As a former "stone age" programmer I had, at that time, as my great debugging tool only memory dumps in hexadecimal notation. So, all that was left to us was to learn and develop techniques of program tracing & debugging.
I've been seeing today most people that I know relying all the burden of these tasks to the visual tools and employing very little or no techniques of debugging at all. Like PRGvs VCX (above) where is the balance ?
I have noticed this too. Many programmers know what steps to take in order to debug, but don't know the discipline of debugging. At the risk of being a snob, I have found that there is a correlation between having a formal education in software engineering (or any engineering) and skill at debugging. I'm not sure this belongs here, though; this topic discusses "stuff I used to do that I don't do anymore". -- Zahid Ali

Contributors: Lauren Clarke Cindy Winegarden Roxanne Seibert df Alex Feldstein Trey Walpole
Category VFP Commands Category Database Structure Category VFP IDE
( Topic last updated: 2001.02.14 10:07:48 AM )