It is interesting the hassles you run into when providing feedback to a magazine. When fragile egos are involved, there is a reluctance to admit when the ball is dropped. So is the case with Miriam Liskin's "The Basics of Visual Basic" article in the January 2000 issue of FoxPro Advisor.

In the interest of making sure the correct information gets out, as well as clarifying some vague points and filling in some missing information, I am publishing here, my letter to FoxPro Advisor.

Why am I doing this? Because my comments that are on the Advisor website have been heavily edited, and IMO, don't accurately illustrate my issues with the article.

Here it is...

---

As somebody who does quite a bit of VB work now, I felt compelled to pass on some comments about your article....

Regarding why to use VB, I am not sure that the VBA and VBScript points you make for learning VB Syntax are the best reasons out there. In fact, when you get down to it, a lot of the syntax in a VB program is identical to that of a VFP program. I am referring only to Object.Property and Object.Method stuff here. Of course, there are differences between Xbase and Basic constructs. Then again, about 80% of this is the same as well. I think you did a great job of comparing and contrasting the looping and decision constructs between VFP and VB :) From a purely syntactical standpoint, I don't think a big issue exists. Most VBA code can be copied and pasted into a VFP program and work as-is. Of the 20% that needs to be changed, there are some simple rules that need to be followed: converting Trues and Falses to .T., and .F. respectively, converting named arguments to the default order of arguments as specified by the typelib, converting end of line designator, etc... A lot of this is fairly well documented now, and once again, I don't this is a big factor in whether folks would use VB or not, or even learn it. People are doing this stuff today without going to VB as a development platform.

IMO, the real differences between VB and VFP lie with COM. VB *is* COM. From an N-Tier standpoint, VB is far superior to VFP. In VB, not only can you define your own events for Async processing. These events, with VFPCOM, can now be recognized in VFP. This is a BIG deal. You have far better access to the Windows API (structures, pointers, call back functions, etc..) as well. You can define default properties, MTS integration is better, multiple interface support, etc.... And, lets face it, ActiveX controls behave the way they are supposed to in VB. These to me, are the big reasons why somebody would consider adding VB to their development platform toolbox.

OK, onto some specific comments:

On page 14, you have a bullet list defining VBA, VBScript, and ASP. There are some problems with the definitions you give here...

VBA is not a scripting language. Rather, it was a subset of the VB language. I believe with VBA 6 - almost full parity with the VB language itself has been achieved. It is also important to note that VBA is licensed by many ISV's to allow the automation of many non-MS products.
VBScript is not just a client-side scripting language.. It is also used on the server as well. In fact, VBScript is a subset of VBA. In reality, it is 2x removed from the full VB language. Not only is VBScript used by ASP, it can also be used in DTS (Data Transformation Services of SQL Server 7.x).
ASP itself is not a scripting language. Rather, ASP is MS's server-side technology for hosting other scripting languages. With ASP, you can use either JScript or VBScript. I know this is semantics to some extent, but I think it is a distinction worth making.
On Page 16, you discuss variables...

Your comment that some variants of VB automatically add Option Explicit to modules. In fact, in VB you can do this as well. VB also as a Tools-Options dialog in which you can specify that variable declaration is required. Making this setting will automatically add Option Explicit to you modules, forms, class modules, etc....

On VB being less strict than VFP with regard to combining different data types in expressions, I think it is important to note that VB actually coerces the data conversion automatically. I for one like this feature of VB. If it is one less call that I have to make to convert a date to a string, I am for it!!!

On page 18, you discuss arrays...

With regard to the Array stuff, it would have been a good idea to include a reference to the VFP COMARRAY function, that allows VFP to work with zero-based arrays. I think integration is a good thing to push. With VFPCOM and COMARRAY and with the COM Support we have with VFP 6 SP 3, folks can now build VB components to accomplish tasks that either cannot be done in VFP, or are very difficult to do in VFP, using VB instead to augment their VFP applications.

On page 18, you discuss records..

Yes, VB supports the notion of a record. However, the way you are framing things here, what you are really discussing are UDT's (User Defined Types). The notion of a record is more in line with the topic of importing and processing data from a flat file. UDT's OTOH, are very powerful. They can be passed to Windows API functions. In VFP, we have to simulate structures.

It is also important to note that you cannot define your UDT's anywhere. Rather, they need to be defined in the context of a basic or class module. Forms are considered to be private modules. The role of BAS and CLS modules is very important with regard to variables, especially UDT's. You can however, define private UDT's in a private form module. Once again, scoping plays a big role. The rules are much more rigid in Visual Basic.

The example you give for simulating a table IMHO would not be done in reality. This is what ADO and DAO recordsets are for. For data of any appreciable size, I think you would see a big performance hit with simulating a table in the manner you show in your article.

On page 18 and 19, you discuss Variable Scope...

If there is one area that cannot be glossed over, it is where you declare variables. I think it is important to clearly distinguish where you can and cannot declare variables. In one of your paragraphs you state how you can define a public variable by declare them with the public keyword, as opposed to the Dim keyword in a declarations section of a module. The inference made here is that a choice exists. In fact, there is no choice. You must use the declarations section of either a form, basic, or class module. In the case of a UDT (User Defined Type), you need to declare those in a public module, which by definition, can only be a basic module (BAS) file.

In fact, this brings up another issue entirely, the concept of module scope. Form and class modules are private modules. Basic modules OTOH, are public to the entire VB Project. When it comes to VFP folks embarking on VB for the first time, it is this module scoping issue, and its impact on variable scoping that makes the learning curve so steep. In reality, it is not that hard, it's just different from VFP.

On page 19, you discuss Collections...

With regard to the statement that collections are equivalent to VFP array properties, I don't think this is a correct statement. In VB, a collection is a bona-fide data type. In fact, the collection data type is an object. When I Dim something as a new collection, I automatically get Add, Remove, and Item methods. I also get a count property. VFP arrays don't come close. Rather, we need to build our own collection class with a custom baseclass and build the stuff manually. Or, you can use the one in the FFC. In VFP, you can iterate through an array with the For Each construct. In VB however, the only place where For Each is allowed is with object types or variants. Here is an example..

Dim x As Variant
Dim foo As New Collection
foo.Add "john"
foo.Add "bob"
For Each x In foo
Print x
Next x
Even though foo is an object, it holds string values, and thus, the For Each will not work, unless my iterator is either a variant or an object. This is one of those times where you need to declare a variable as a variant. From a performance standpoint, most folks shy array from for each construct in VB, unless they are working with objects. Therefore, the following would be a better choice:

Dim x As Integer
Dim foo As New Collection
foo.Add "john"
foo.Add "bob"

For x = 1 To foo.Count
Print foo.Item(x)
Next x



On Page 19, you discuss constants....

I think you mixed up metaphors here between constants and enumerators. In VB, you have both. In VFP, you only have one, constants. In VB, you can work with a single constant like this:

Const foo = 1

Or, you can define an enumerator that groups a bunch of related constants together like this:

Public Enum Foo
firstone = 1
secondone = 2
End Enum

IMO, your article does not make this important distinction. Rather, the concepts of constants and enumerators gets lump together. You can have constants without enumerators. However, all enumerated types are constants. Once again, this is a great opportunity to compare/contrast the two environments. Here is a good example of how the enum types can work for you. Have you ever wanted a variable to only hold a pre-defined set of values. With enum types, it is easy:

Dim x as foo

Now, in code, when you attempt to assign a value like this:

x =

Intellisense will automatically kick in to give you a list of constants that are defined in the foo enumerator type.

The text on program flow structures looked good. One detail that is missing however deals with the fact that VB does not short circuit boolean expressions. For example, consider these two VB functions:


Function test1() As Boolean
Print "test1"
test1 = False
End Function

Function test2() As Boolean
Print "test2"
test2 = True
End Function

If you have code like this: If test1() And test2() Then...

Even though test1 returns False, test2 will still be evaluated. It is a stupid "feature" of VB that I am glad VFP does not share.

I know it was your intention to keep things simple. However, I think there are some serious issues and omissions with the article. Maybe it is the focus on syntax. I just don't see that as the crucial difference between the two environments. I agree that it should not be an either/or situation. In several FoxTalk articles, I spent considerable time on how to integrate both VFP and VB. When talking about integration, no doubt that discussion will lead toward COM. Unfortunately, your article does not address that aspect of VB. Once again, I don't think the syntax is the issue. Sure, you will no doubt run into some differences. However, those issues are quickly rectified once you know where to go. The bigger issue is the WHY. Why should I learn VB? If you are going to "convince" folks to learn something new, then you need to address the why.

Your first paragraph sets up the premise well. The second and succeeding paragraphs unfortunately miss the mark. Automation itself is not an incentive to really learn VB. There are a ton of VFP-specific resources that obviate that need. VBScript is so simple that I again, don't need to learn VB to program in VBScript. And, most of the code that ships with COM/ActiveX controls can work as-is in the VFP environment.

If I were going to go down the road of convincing the die-hard Foxheads of why they should learn VB, I would show them the things they can do in VB that either cannot be done in VFP, or are very difficult to accomplish in VFP. For example, a COM wrapper around Win32 API functions. I would be more apt to do this in VB as opposed to VFP. Another example deals with Async processing and events. In VB, I can not only raise events, I can define my own custom events - that can be surfaced in COM Clients such as VFP, VB , etc....

All of this is meant to be constructive, and I hope it is taken as such. I agree that the VFP community needs to be more aware of other tools, especially Visual Basic. However, I have some rather well-defined viewpoints on how that material should be presented. It is not an easy topic to present. As I see it right now, several problems exist:

1. The focus on the relevant decision points that would lead a VFP developer to use VB is incorrect.
2. The treatment of some aspects of the whole topic is just too superficial and at times, incorrect.
3. This stems from point 2: there is an attempt to cover too much material in one article.
4. The length of the series is too short. 2 installments is not enough.

IMHO, the IDE is exactly the first place to start. The developer needs to work with the IDE. The grammar and syntax does little good if he/she does not know what to do once inside the VB IDE. After that, you can have installments that have these areas of focus for each article:

1. Intro to the VB IDE
2. VB and VFP Language constructs - How they are the same, How they are different
3. Data Types, Variables, and Modules (Form and Basic)
4. VB Class Modules, Interface Inheritance, and how VB implements OO, events, etc...
5. VB and the Win32 API, how they work together....
6. VB and Data....
etc, etc....

Very granular topics for each article. This is how the material needs to be presented. There is just too much to do it any other way. The alternative is to not give the topic the justice it requires..........

It is a valuable service to the VFP community to present these VB topics. I am glad that Advisor is taking the issue head on. It is my wish to help this process along and to make it as good as it can be....