Hi John K.

>You seem to be under the impression that VFP people only know VFP.

No. Most VFP developers develop in just VFP or only know VFP.If you use ActiveX Controls that ship with VFP or make Windows API calls, I still regard that as basically using VFP. I understand there are quite a few folks who are conversant in other tools.

>Now...if I'm to believe some MS documentation, I already have an enterprise >solution marrying VFP to SQL Server. If VFP is everything that the Fox team >at MS tells me it is, then I have good cause to scream bloody murder when an >ActiveX control doesn't work.

I agree and made that point. My point is that many folks just say things like MS VFP Marketing sucks or MS isn't being fair to VFP. To me, this is all non-productive. Life is not fair. I think if there are technical deficiencies in the product, you, I , or anybody else should scream loud and clear. All I am saying is that I would not wait for a solution from MS as there is already one there. If I need events in a middle tier item, I will use VB - because I have to deliver a project. Would I go back to VFP later if a future version go that functionality - probably - but I would have to wait and see.

>And...I might add....there is little or no documentation from MS that >specifically tells me that VB is used here and VFP is used there. In fact, >the one paper I did read that was a comparison of VFP to VB to Access ended up >by saying that all things being equal, go with what you know.

So basically, the paper was useless<g>



>By saying not to expect ActiveX support or other features is like telling me >not to expect my trunk door to work on my Chevy because Chevy is not GMs >favorite car and I should have bought a Pontiac.

I said don't expect radical change in this release (6). It's too late now. Its time to start hammering home to people that if they want better ActiveX Support in the product, the earliest it will come is in a 6.x or 7.0 release. I do believe full ActiveX support should be in the product. I am very much on record with that. In this case, I am separating my wants from what is based in reality.

>If VFP has a UI I expect it to work. I don't buy this VFP is >middle-ware and >little else....I didn't buy the car for the engine. The trunk door, dome >light, and tachometer better damn well work and work well.

I agree. But, what are you going to do between now and sometime in the future when and IF VFP aquires full ActiveX support and some other critical features that are not in the system right now. Remember, it also takes the buy in from ActiveX Control Vendors to test thier stuff with VFP. MS can't make those folks do that. I have come to learn that there is no real ActiveX standard. By default, what works in VB is the de-facto standard.

>Most VB developers I know wouldn't know a foreign key, for example, if it bit >them in the ass. Talk about blinders. Most professional VFP developers >understand the bigger picture, IMHO, far better than VB developers who are far >more closeted and professionally short-sighted.


Your point being that most VB developers don't understand how to build database applications - then I would agree. However, my argument is with the comparision of tool features. Whether VB developers are good or bad at developing DB apps in VB, it is of now consequence to me because I know that I could succeed. Sure the DML is not there, but then again, that really should not stop you. After all, have'nt you written at least one VFP app that works well with data - but does not use the old XBase DML????


>As to the MCP issue: I, for one, am looking at the bigger picture with the >new MCSD track. VI,VJ and SQL Server people are getting kiboshed. Again, in my >experience, Java and SQL Server people are much more heads up in solution >development than VB people. Yet, VB (and VC) developers are given the inside >track to certification and they don't even have to prove they understand >Windows Architecture anymore. Does this make sense? MS is really screwing >the pooch here, making things easier for VB programmers and harder for >developers with arguably stronger architectural and big-picture skills.

No argument here. I am on record stating the whole MCP thing is lame as to how it relates to both VFP and other tools left out in the cold.


>I think you're selling VFP people short and I think you're giving way to much >credit to the VB dittoheads.

Where did I say the VB developers where superior to VFP developers?? I am trying to compare the tools and make suggestions on how the VFP community can productively channel things.