John,

We all like to use the ol chestnut of 'say your user suddenly demands a global change like a new font. . .'. Let's face it, we usually cover off basics like that very early to avoid it later or, more likely, it ACTUALLY never happens! A more likely change of a 'global' nature might be along the lines of:
a) he's decided to expand and will have a partner who needs same services from same system but separately identifiable; or
b) They are opening another store on the other end of town and want to control both from the same system; or
c) The time of day that certain transactions happen has suddenly become of interest.

OOP might be helpful with these "problems", but none are a 10-15 minute job!

I guess I could say 'Sorry, I can't do that for you, but I can change the fonts in 10 minutes for you if that'll do instead'.

What I am trying to get at is: just because a tool NOW gives us the ability to do some things that were a pain to do at one time, these are still the very trivial and cannot be used to justify one product over another.

I happen to prefer VFP, even with its poor documentation and plethora of workarounds and documented bugs (up to 109 for VFP 5.0a as at last week!).
But that is no reason to badmouth another product.

Cheers,

Jim N

>> 2a) Search the VB forum for messages written since Jan. 1, 1998 containing the word "workaround" (9 messages). Then search the VFP forum for the same (183 messages)
>>
>
>Gino, Gino....sigh.....could 2a) be attributed to the simple fact that, on the UT, there are a trememdous difference in the number of posts? Many, many more VFP posts than VB posts.
>
>All else being equal, a true OOP language used with OOP methods should be much faster to develop in than an equivalent procedural GL....as someone else pointed out in another post:
>
>An application has 20 screens. The client demands ...let's say ... a global font change. I can do it by modifying a few classes in VFP...maybe a 5-10 min change. Recomplile. Viola! In VB...I have a major major retooling problem.
>
>So, maybe *some* of the development time issue has to do with what you're familiar with and how you use it. But a lot of the time has to do with the capabilities of the development environment. VB has no visual classes, little inheritance and/or polymorphism. You cannot save visual objects as classes. When you do something simple such as change an object name, you have to recode your declarations (I won't dignify them by calling them methods).
>
>The day that VB gives me as much OOP capabilities as VFP, I will no longer argue this point with you...until then, I can't be convinced.