The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Fat client Application

I currently planning the development of a fat client application for Microsoft Windows users. The application will be designed to be fully functional without any LAN or WAN connection but will have the ability to share info with other users via the Internet and a central database.

I am thinking the best programming tool for this type of application would be VFP. However, it is clear to me that Microsoft is going to roll VFP into the .Net framework in the future. My problem is do I develop this application in VFP and hope that Microsoft gives me a decent upgrade path to .Net or just develop the application in .Net now?

The problem, in my mind, with developing the application in .Net now is a .Net/access ( or whatever DB I use ) solution is not going to be as fast or efficient as VFP for local data processing. If I develop now in VFP am I going to walk into the same trap as VB6 users? Or will I get a decent path to .Net?

Greg G.
Wednesday, December 28, 2005
Have you had a look at SQLite? This is a very nice database with speed that might work for you with C# or VB and .Net.

Just a suggestion...
Wednesday, December 28, 2005
>>However, it is clear to me that Microsoft is going to roll VFP into the .Net framework in the future.

I don't think so, there are elements of VFP that can't be implemented with .Net (i.e. Exec()). Also, with the slowly declining popularity of VFP, there is little incentive for MS to try to shoehorn VFP into .Net.

Yes, always appears on the "wishlist for VFP X.0" on the FoxPro Wiki - - but the many problems with this are pointed out by the experienced VFP people. Along with the fact that if MS wanted to do this, they would have done it several versions ago.

Besides, why not develop with the latest VFP version? It won't suddenly stop working even if MS cones out with a .NEt version - look at the number of people still developing with VB6.
RocketJeff Send private email
Wednesday, December 28, 2005
One suggestion:

Delphi 6.0 or 7.0 + firebird database (embedded) + interbase objects (

You can not go wrong with the vast amount of existing source code and components at your disposal including express bars from

Your application will scale from single user (embedded) to multiuser.

Oh, and if you need a remotable solution (n tier) with multiple transport channels, see

For source code questions see:

Thursday, December 29, 2005
>The problem, in my mind, with developing the application in .Net now is a .Net/access ( or whatever DB I use ) solution is not going to be as fast or efficient as VFP for local data processing.

How fast do you need?  On modern hardware, you can do a LOT with almost any language (.NET ones included) with nothing but a little care and a good performance profiler.
John Rusk Send private email
Friday, December 30, 2005
In other words, while I don't know anything about your particular app, I think it would be a very rare app indeed that was workable in some other language but not in .NET - certainly on machines 1Ghz and better with, say, 512 MB+ of RAM.  Admittedly your mileage may vary on older hardware...

If older hardware is a problem, I'd suggest Delphi.  It's efficient on old hardware, and _already_ has a migration path to .NET.  (You could even compile to .NET as you develop, to make _sure_ your eventual migration will be smooth).
John Rusk Send private email
Friday, December 30, 2005
VFP will be fine but I'd use an existing 3rd party class architecture rather than invent more wheels.  Its the class architectures that you can build and use with VFP that make it so flexible and powerful to develop in as well as that it happens to have data handling built into the language.

I can't see anything like a .NET VFP ever happening, VFP's whole design based upon using database tables to serialise classes, methods and events just doesn't fit but you can interop with .NET now.

Not that I've had much call to do so.

The environment I use is Codemine and I'd recommend it but there are a number of others which provides similar features.
Simon Lucy Send private email
Saturday, December 31, 2005
Thank you for the replies. Let me clarify a few things.

1.    I know, or would really be surprised, if there were ever a .Net version of VFP down the road. Based on what I read and hear I think Microsoft will try to bring some of VFP data handling/processing capabilities into the .Net framework and let VFP slowly die.

2.    I don’t think older hardware is going to be a big issue. Most of the users will be running decent hardware.

3.    Other languages might be a good choice however the bulk of my programming experience is with Microsoft products. A lot of C++/MFC and VFP as well in the last few years C# and the .Net framework. I am not sure if I want to develop a new, fairly involved application, while learning a new programming tool.

4.    I think VFP is the right tool for the job but 5 years down the road if I am still supporting/enhancing this application will I be able to keep it current and take advantage of the last operating system features? Right know I am thinking I better write in .Net and probably Access even though from my perspective it seems like changing the spark plug in my lawn mower with a pipe wrench rather than a 7/8” deep socket.
Greg G.
Saturday, December 31, 2005
Have you considered Borland C++ Builder? There is a new version with BDS 2006. The only think you will have to learn is VCL (the framework) and the IDE. I used OWL and MFC for years and the switch to VCL was painless. And I could use my old C++ code, something I could not do with VB or Delphi.

Another option is VB, which is a good choice if you are a big COM user.
MBJ Send private email
Thursday, January 05, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz