We had to write a quick app for a client the other day. I wrote most of it over a weekend and then wrapped it up in InstallShield so the client could download it from our web site and install it.
Their requirements very simple (this app only had 5 tables, 5 forms and 6 output html pages), and is possibly the smallest commercial app we’ve ever written. It basically captured auction sales results, did a bit of formatting, pumped them out to XML, after which HTML files presented them via a stylesheet. The client wanted control over formats and graphics so HTML as the simple answer. However, one requirement was it had to run on pretty vanilla existing machines (ie low specs and not much RAM).
So, I wrote it in VFP and used InstallShield to install the runtimes along with the app. The total download was 7MB including runtimes (I didn’t need the MTDLL runtime so there’s 3.8MB saved), app and help file.
This little excercise reminded me of why I love Visual FoxPro so much. Because without VFP what would I have used? (Probably Access, but then I would have had to ensure my client had Access installed). I was reminded of Rick‘s article a while back on why HTML Help Builder is not going to be re-written in .Net any time soon. I agree with his thoughts – what could I have done other than use VFP? I wouldn’t have liked to force our client to download the .Net runtime (at over 20MB) and then ensure Access was there for the database (or worse, MSDE). Perhaps I could have used XML throughout instead of needing tables at all, due to the simplicity of the requirements (less than 1000 records in this case)…
But here’s the point, VFP definately has a place in the developer toolset. Don’t get me wrong, VFP is great for the big projects too, but here’s a simple example of where VFP was the best choice.