Bravo Ken...

I went through pretty much the same thing at a Bank. They brought in the VB 'Guru' cause they were gonna switch everything to VB from Fox. I remeber the
coding we had to do to manipulate data and the data sets and etc etc etc..

The thing that fried me was the IIF Statements in VB. Talk about useless. I mean it evaluates the entire statement.

Anyway.. Thanx Ken! U said it!

>>Hiya JVP!
>>
>>>
>>>Finally, if VB is that easy to use, could you code an app today in VB? My contention is that learning syntax is one thing. Being able to architect and write an app is quite another.
>>>
>
>I was told that if you know VFP you can pickup VB in a couple of weeks...so I took the job and started coding in VB after working with dbase/Fox since 1984.
>
>I wasn't left alone, the company have half a dozen VB programmers I could turn to. The architecture was not big deal...forms and tables. The thing that fried my brain was the hoops I had to jump through to get things done that were a snap in VFP. I'd go ask one of the VB programmers how to do this, that or the other thing. After I got the answer is was *always* "You have to do all that just to do this??!!!"
>
>To support my point, try this. Print out a list of commands and functions for VFP. Then do the same for VB. One's huge (VFP). One's dinky (VB). For about 3 months I found myself jumping through hoops to get *VFP simple* data manipulation done and finally said "Screw this!" and quit the job.
>
>God Bless Hot'lanta...only took 2 days and 1 interview to get another job at a Fox House. In fact, the company was planning to take their FP2.6 application and recode it into 32 bit. The owner had been contemplating switching to VB, and asked me what I thought about that. I told him!!! And when I was done he said something like:
>
>"The guys that have supported VB have only given me generalities as to why it is better. You gave me *specifics* why it is not. Take this job and redo the application in VFP."
>
>So, to any lurking VB spies in the crowd, I really like some *specifics* as to how VB is a superior platform to write a *data management and information* system. You can start by explaining the benefit of having to write a procedure just to get a date that is not mm/dd/yyy (such as 7/2/1998 vs 10/22/1998) out of a SQL database into a masked edit control without getting an error message. Or how about the fact you can't bind a control to a memory variable. And I love to know how VB's text property (AKA "value" in VFP) ability to *only* hold string values speeds up data maniuplation. Sure, IIF() is great and I was able to live without it in VB, but the fact that SELECT CASE (DO CASE in VFP) must include the variant that is used in the rest of the SELECT CASE statement, eg:
>
>SELECT CASE mvar
> CASE this *using mvar!*
> CASE that *using mvar!*
>ENDSELECT
>
>Now then, it took about 2 of these to realize I need to CASE something outside mvar, so here came a huge nested IF/ENDIF...that *really* saved me a bunch of time ;)
>
>But not near as much time I spent on the RAD of the app when it came time to debug without a command window. That was real fun and super productive, typing in the names of all the variants in the Watch window and *quessing* as to what the data environment was since I couldn't see what tables were open. I remember how cool SCAN/ENDSCAN was when it first came out, so I really had a good time learning how to live without it and go back to FILTERS and coding a DO WHILE ! EOF() routine. And the joy of having the *ENTIRE* code for a form in one huge ass file so I could hunt and peck for the SUB's instead of clicking on the method's name gave me plenty of *relaxing* time when writing the app that broke the stress of the deadline of getting the thing done...reminds me of the good ole' FoxDOS days.
>
>WOW! That sinches it...I gonna' give them guys a call and see if they'll take me back...WAY back ;)