And that is something to consider. With macro substitution, we can give end-users the power to do any of the low-level stuff that we can do in the command window...a nice tool for a tech support desk. It also makes a lot of other tasks easier.

I will say this...if a program takes a long time (30 seconds? grab a coffee and give me a break), who cares? Our users load our VFP system and leave it there all day on all their machines (along with 3 or 4 other apps). So the initial load time doesn't really matter. If a form takes a half a second to appear, it is not a big deal. If serious number crunching takes 10 times longer, it is not a big deal where I work...because our math is not too demanding (ie. if it take 1/10 of a second in VFP, does it make sense to go to Delphi or VC++ to make it 1/100 of a second? I think not.). So there are apps where VC++ makes sense, but there are also apps where VFP makes sense. People who are making a mountain out of a mole hill (with VFP weaknesses) must be mis-directing their frustration. I think possibly they are just not good programmers and they think a different tool will make them better. Honestly, when I hear "I'm gonna learn VC++ and blow your apps away" or whatever, I am not impressed or intimidated. I prefer to look at what I've done, not talk about what I'm gonna do. I have systems that I am proud of...some in C+, some in VB, and one in VFP (it is the only one I've ever worked-on in VFP). I don't think the tool matters as much as the programmer.

If VFP dies (which I don't think will happen, and I hope it doesn't), I will pick another language. If this happens, I will be giving-up some good things and I will be gaining some good things...but the bottom-line is ME. Am I a good developer or not? Any bickering about languages and what is better and what will last doesn't matter...if one dies, it will not affect a good programmer for long.

Take care,
Joseph C. Kempel

>A native compiler would be nice, but we'd lose macro substitution.
>
>George