Hi Gang,

Yes, this is probably going to sound a bit harsh - but the truth often hurts.

In case you have not noticed, VFP is not MS's strategic tool for building enterprise applications - VB is.
Anybody who wants MS to invest equally in VFP and VB - really has unrealistic expectations -
at least from a business perspective. Microsoft is not a charity - they have a responsibility
to thier shareholders and employees to turn a profit.

When looking at VFP - dollars invested have to sync with dollars earned. That is budeting 101.
VB outpaces VFP 10 to 1 at least. VB has 80% of the Rad Tool Market. As a result, VB gets the
bucks - as there is a greater ROI.

For the past 2 years - I have heard continually about folks speculate as to the future of VFP.
Speculation is really not required as I think VFP's role is pretty much known.

Here are my 2 cents on this issue:

If you are developer who creates apps for a client base that is happy with your work and you
choose to develop apps in Visual FoxPro - I would say that VFP will be a good tool for you
for many, many years to come.

If on the other hand, you a developer who is going after contracts where n-tier architecture
is involved and you need to interface with other developers - then you may have to augment
your toolset with VB. Chances are in a n-tier, Client/Server enterprise wide project - VFP
is not going to be the central tool. More likely, it will be tools like VB, VC, VJ, VI.
With the exception of VJ, all of these tools have a clear role in application development in the
enterprise. Java is new and there is still a wait and see attitude. Microsoft has and is
developing VJ as a hedge. If Java really takes off - MS wants to be a player.

As a member of that team, you toolset will need to mesh with the other tools. If the tool standard
is VB, then you are going to have to be proficient with VB - if you want the job and
consequently get paid. Just because you proudly proclaim VFP can do this and that will carry
little or no wait in an organization who has spent time standardizing on tools and as an
annual IS budget of millions of dollars. To get those contracts - the price of admission is
fairly easy to determine - use your VFP expertise to learn VB. Once again, if this does
not apply to you - and VFP works - and you are making a nice living - what exactly are you
complaining about.

To complain about ActiveX Support on the UI or the lack of abilty to surface COM Events in
COM Components - or anything else that is not there that would legitimatley improve the
product - those are all legitamate beefs. The point is that you must be constructive in how
you articulate those beefs. Scream up and down continually saying that MS marketing of VFP
sucks is not the way to go. History has proven that. Also realize that to integrate certain
things - may prove not to be feasible. When that happens, you may need to use a different
tool. I would not wait for MS to add the needed functionality into VFP. This is particulary
true with regard to UI issues. It is fairly clear that VFP is positioned as a middle tier
item. So, with that said, you should focus your energies on improving VFP as a middle
tier item - better support with MTS as far as concurrency goes and the ability to
surface events.

The VFP team, Randy and Robert in particular, are open to ideas on how to improve the product.
I know because I spent several hours with Randy at Tech Ed going over things. So, to say
VFP is dead and to continually ring out the death chant is rediculous and un-productive.
VFP is alive, well, and is a great tool. But, it is not the only tool. The days of every-
thing contained in one tool are over. What folks like Robert, Randy, and the rest of the
team are constrained by is a budget. My guess is that VFP's budget is not as big as VB's.

The problem facing those folks is pretty big: how do we improve VFP so that it can integrate
with other tools in VS - and still keep within our budget.
Improving the interface, while nice for VFP developers - does nothing
for MS's bigger objective - Windows DNA and tool integration. Remember, there is a bigger
picture here. Bottom line, get the VFP blinders off.

You see, that is why MS bought Fox in the first place. 1, if xbase took off, MS wanted to be a
player. They bought the best - Fox Software. They not only got a great tool, they got
great people as well. Well, 6 years later, the xBase standards committee is dead and I think
it is safe to say that xBase did not take off as a standard. So, was the Fox aquisiton
in vein. No way.

You can trace the strides MS has/is making in becoming a data tools company to the
aquisition of Fox. I dare say MS gained a distinctive competence in data when they
bought Fox. 6 years later, anything data related at MS, Fox or the Fox Team had and still
has a role. As a result, we have better data tools that can be leveraged in other
tools. To expect that MS was not going to integrate the acquired technology into other
products would mean that one would have to be a bit mis-informed. Heck, I remember
Roger Heinen back at the 1993 Devcon stating MS's integrated tools strategy. I am
sure Fox's role then was bigger than it is now. But hey, times change. Ask which
tool is better equiped for COM and COM+ - it is VB. Should this be a surprise?

Basic has been around since the first IBM PC shipped. It has been part of the MS culture since
close to day 1. Bill Gates is a big believer in what the Basic Langauge can accomplish. FWIW,
the stats seem to support him. After all, VB did not get to where it is by being a totally crap
language. Are there things about VB most folks wish were different. Of course, I think you can
find flaws in any language. To me, what is impressive, is that you can do things in VB that
where originially in the dominion of C developers. A few years ago, that would have been
unheard of. Today, it is an accepted fact. VB has come a long way.

The flaw with most on the VFP side of things is that all events are viewed from the VFP
perspective. VB developers are just as guilty of this BTW.
You can scream up and down to a VB developer how great VFP is. However, if he/she
never looked at VFP, isn't it really a moot point? After all, the VB person could give you many
reasons why he/she uses VB? But, if you never looked at or worked with VB, you really can't
comprehend what the point he/she is attempting to make. The reverse is true in that the VB
developer cannot comprehend the points the VFP developer is attempting to make. Bottom line,
unless you have worked with a specific tool, you should probably keep an open mind
about that tool. Don't go by what other people say. Go by facts - ones that you have learned
for yourself through first hand knowledge.

Okay, so where does that leave VFP? I dare say that 80% of what we can accomplish in VFP, we
can do in VB as well. What about the other 20%? Well, much of that can be accomplished as well,
but it probably involves more code. Obviously, the native DML is not in VB. Also, VB is
object based - not object oriented. That certianly not to say that VB is an inferior tool. It
just means there is a gap between the products. Look for every flaw in VB, you can find one
in VFP - and vice versa. Its a zero sum game.

MS has a great case study now of moving a procedural community to OO. We have had some great
tools to work with that really puts us in a good position to learn other tools. I am not saying
to throw the baby out with the bath water. I am saying that if you are looking for guidance as
to what to do - learn another tool - probably VB. If you learn VB, lets see, you will have
little or no issues with VBA, VBScript, Windows Scripting, VI, etc. Should you still use
VFP when it is appropriate, sure. But, don't expect that VFP is going to get all of the features
that VB has. Economically and financially, it makes no sense for MS to do this.

The present and future is COM/COM+ respectively. VB is geared toward those object
technologies. Do we really need to ask any more questions?????

So, if you need an interface that supports ActiveX Controls better, try VB or IE. If you
need a middle tier that can surface events - use VB? If you can develop apps in VFP to your
cleints and they are happy - use VFP? If you view this from the perspective of 1 tool, you are
really missing the boat.

With regard to the MCP issue - has anybody stopped to think about folks who primarily
develop with VI, VJ, and VBA? Are they not in the same boat as VFP Developers? Why does'nt the
VFP community look at the bigger picture. If you primarily development in VI, VJ, or VBA, you
too will need to focus on VB or VC as a core requirement for the MSCD. Bottom line, the issues
are much broader than what is happening in the VFP community.

So, what do you do. You take this valuable time to learn something else - like VB. In order
to abandon VFP. No. To augment VFP where VFP is lacking and to give you more flexibility as
a developer - yes.