FoxPro Ramblings

There are basically 5 things I would to see Microsoft do to Visual Foxpro, and No not one of them is in "Sedna."

1) SET CaseSensitivity ON/OFF
On a daily basis I may work in as many as 5 different programming languages at a time, and only two of them are not case sensitive VBScript, and Visual Foxpro. There is nothing more frustrating than working on a C# project for a week, and then return to a VFP project and spend all day looking for a bug that turns out to be due to having a brain fart and writing code thinking your in one language while you are in another.

2) Set TypeCastVariables Strong/None
Yup you guessed it, I'm of the belief that we as programmers should DEFINE what we use variables for. This has been one of the more frustrating things about VFP for me personally. But if Microsoft and the VFP community insists on keeping it this way, then how about making the following work:

"Hello World, it is " + 40 + " degrees out"

If you insist on not typecasting your variables, then who cares if the variable is string, numeric or date, just make them combine using common sense.

3) Set VariableScope Correct/FoxproWay
I don't know who's bright idea it was to make a variable remain in scope when you leave the function, but that person should be hung. I cannot think of any one single thing that I have WASTED more time on than debugging code and finding out after days of looking that some other function has stepped on a variable and changed it's Typecast (another reason for #2), or changed it's value.

If you don't like this one, then at least make local variables LOCAL.

4) Can we PLEASE have a real report writer?
Don't you think we have paid more than enough in time and resources doing the best we can with Modi Report? The changes in VFP 9.0 are great, and were LONG past due, but instead of the "Report Listener" Object, it would be much nicer to be able to either embed objects like List Boxes, or even better maybe make the report an actual object that would allow us to embed reports inside of each other. Countless times I have needed a report that allowed me to have embedded detail lines inside of a detail line. In every case I have been forced to code it myself which ends up wasting GOBS of time because I first of HATE writing reports, and HATE even more hand coding them.

5) I would to see a new Project Manager, and Form/Object Editor (yes I know that's two items, but they are kinda one.

For the Project Manager I would rather see a "Solution Explorer." (Oh no that sounds a lot like Visual Studio, and yes that's EXACTLY how I would like to see it work

For the Form/Object Editor, I would like to see a lot of changes. First off, I would like to see the tools work like Visual Studio, where I can un-pin them and they slide off the screen, and then mouse-over returns them. The floating and dockable tools/Properties were nice when VFP hit the desktop, they are a little outdated. And for me they are always in the way, and I'm always finding that I either have to minimize the screen, or the properties window or something to find them.

As for the other changes I would like to see in this area, its pretty complex, but I will take the time to post them as best as I can.

Get rid of the concept of storing Class Libraries in DBF files. This was great when one form = one DBF, and one Report = 1 DBF, but it's an outdated now, and something new is needed.

Instead of using DBF's to store the Class Libraries in, use PRG's. The switch would be fairly easy actually, when you add a class library to the solution, you create an empty PRG.

When you Add an object to the Class Library your PRG gets:

DEFINE CLASS clsObjectName AS ParentObject
ENDDEFINE

Now when you add a property to the Object you get:

DEFINE CLASS clsObjectName AS ParentObject
String cPropertyName =""
ENDDEFINE

Then when you Double Click on the Object you are taken to the actual source code, and not to a memo field.

There is actually a legitimate reason for my wanting this. The current Object Editor is good, and does a good job, but it lacks a few things. The biggest one is the ability for the developer to define in detail how the object and it's contained objects are initialized.

For Instance I ALWAYS want my DataController initialized BEFORE any control on a form. As it is now the only way I can do that is to put source code in the OnLoad Method of a form. I would rather drop the container on the form, and use the properties window to make the necessary changes to the container.

Anyway, what's Ironic about this wish is that Foxpro 2.5's screen editor actually DID have something along this line. It stored the forms in DBF's but before you could actually build an application it used _GenScreen.app to generate xBase code that was then compiled into your program.

Microsoft took this option away in Visual Foxpro 3.0 in favor of internally converting the DBF to Fox Code.

And to make this even more Ironic is that .NET Windows Forms work exactly like I want Foxpro to work. How funny is that???

Now I have written a program that took the DBFs that were created by the ObjectEditor and scanned them creating a PRG for me, but after 2 or 3 applications I canned this idea because I started having flashbacks of the days when I had to upgrade an application from DOS to Windows, and because I had written code directly into the generated code I was unable to use the conversion wizards.

One of the things I have also considered is to learn how to write a Plug In for Visual Studio, and use VS to build my Class Libraries for me, but I'm not too sure I want to try doing this just yet, I am holding out hopes that Microsoft will re-consider removing FoxPro from the Visual Studio Suite, even if they never make it .net, it would still be nice to use the IDE from VS.

So if anyone from Microsoft is reading, or friends of Microsoft employee are reading this, PLEASE add these to the wish List for me!!!!

So far I sound like I am pretty negative about Foxpro, but honestly I LOVE VFP, and I am a strong supporter of the product. These topics are at the forefront of my thoughts right now because I am dealing with them on a daily bases for work.

Stay tuned, coming in the next blog or two I have some thoughts to share about Visual Foxpro and Web Development, and why I think products like West-Wind's Web Connect and FoxWeb are dead, and should be buried. The continued marketing of such products are doing more harm than good!!!

My plans are to get into how to REALLY use Visual Foxpro for enhancing your Web Sites without KILLING your server's resources.