If I don't use OLE in my application, can I remove it from the install disks?

Visual Basic Version: VB 4.0, VB 5.0, VB 6.0

Issue: The install program for a VB 3.0 application that fit on one disk now requires two or three. Most of the extra files seem to be related to OLE. If your application doesn't specifically use OLE, it seems reasonable to be able to remove these from the distribution disks. But, this is not the case.

VB *is* OLE. That means that VB itself uses OLE. So even something simple like text1.Text is an OLE call.

Bottom line is, you need those OLE files!

What am I passing when I use an object as a parameter?

Visual Basic Version: VB 4.0, VB 5.0, VB 6.0

Issue: When working with object hierarchies, there is frequently the need to pass an object reference from one form, class, or module to another. For example:

Public Sub DoSomething(currentPerson as CPerson)
   <Code here>
End Sub

This code passes an instance of the CPerson class to this routine. Well, this is not a technically accurate statement. This code actually passes a pointer to an instance of the CPerson class. This means that you are only passing the reference to the object, not the object itself.

So, what happens if you add the ByVal keyword as follows:

Public Sub DoSomething(ByVal currentPerson as CPerson)
   <Code here>
End Sub

This does not pass the object by value. Rather, it passes the pointer by value. This means that the routine can make permanent changes to the object, but not to the object pointer.

Do I get better performance with a Public variable than Property Let/Get statements?

Visual Basic Version: VB 4.0, VB 5.0, VB 6.0

Issue: If a form, class, or module in your Visual Basic project needs a programmer-defined property, you can define the property as a public variable as follows:

Public sLastName as String

Alternately, you can keep the property private and then expose it as desired using Property procedures as follows::

Private sLastName as String

Public Property Get LastName( ) as String
   LastName = sLastName
End Property
Public Property Let LastName(sName as String)
   sLastName = sName
End Property

If you don't plan to have a lot of code in a Property procedure, should you just use a Public variable to improve performance and cut down on the coding?

Well "Yes", using a Public property does cut down on the amount of coding, but you will only get slightly better performance. Even if you use a Public variable, Visual Basic internally creates Let and Get property procedures for it. To verify this, try the following steps:

1) Create a new test Visual Basic program.

2) Insert a class module and set the Public property of the class to True.

3) Add the Public statement: Public sLastName as String.

4) Use the Make EXE option to make the executable.

5) Use the OLE2View application that comes in the Tools\Pss directory on the VB 4.0 CD.

6) Select View Type Library from the File menu and select the executable created in step 4.

7) Notice in the functions dialog box that the sLastName function appears twice.

8) Check out the FUNCDESC window for both sLastName functions. For one of the functions the invkind will be "PROPERTYPUT" and the other will be "PROPERTYGET".

So create Property Procedures. You may not think of code now to put in them, but you (or someone else) may want to in the future. If you don't like typing all of the extra code, try an Add-In such as the Class Wizard Add-In available in the VBPJFO forum of CompuServe. It automatically creates the declaration and appropriate Let/Get Property procedures for you.

How is the performance of the For Each/Next Syntax?

Visual Basic Version: VB 4.0, VB 5.0, VB 6.0

Issue: When iterating through a collection, is it faster to loop through each element or to use the For Each/Next Syntax? and Why?

You can iterate through a collection just as you iterate through any array by using a For/Next loop.

For i = 1 to 10
   <Any code here>
Next i

Alternatively, you can use the new For Each/Next syntax as follows:

For Each tempTask in Tasks
   <Any code here>
Next

The answer is that the For Each/Next syntax is faster.

Why? The For/Next loop requires an OLE look-up for each iteration whereas the For Each/Next syntax uses OLE's Next method in the ENUM interface of the collection.

By the Way - Did you know that you can also use the For Each/Next syntax for simple arrays? For example:

Private Sub Form_Load()
Dim sum As String
Dim x As Variant
Dim a(10) As Variant
   a(1) = "A"
   a(2) = "B"
   a(3) = "C"
   a(4) = "D"

   For Each x In a
	sum = sum & x
   Next

   MsgBox sum
End Sub

What is really happening when I set compatibility?

Visual Basic Version: VB 5.0, VB 6.0

Issue: When creating ActiveX components, you can select one of the following compatible component options from the Component Tab of the Project Properties dialog box:

•No Compatibility
•Project Compatibility
•Binary Compatibility

These settings define how compatible future compilations of the component will be with the existing component. But what is really happening when one of these options is selected?

Selecting Project Compatibility or Binary Compatibility enables the file location textbox. You can then select the compatible source file that the newly compiled component will be compatible with.

During compilation of the component, Visual Basic opens the compatible source file, reads specific information, and then writes the compiled compatible file to the destination specified on the Make Project dialog.

There is currently a defined bug regarding this process. If the user selects Binary Compatibility, Visual Basic does not close the source file for an ActiveX EXE Server until Visual Basic itself is closed. This is not the case for the Project Compatibility option, nor is it the case for ActiveX Control projects. The result of leaving the file open is not an issue unless you select the same filename and location for the destination file, which is very common. If they are the same, you will encounter an error.