The difference between Sub and Function in VB6

For nearly all programming purposes, VBA and VB 6.0 are the same thing.

VBA cannot compile your program into an executable binary. You'll always need the host (a Word file and MS Word, for example) to contain and execute your project. You'll also not be able to create COM DLLs with VBA.

Apart from that, there is a difference in the IDE - the VB 6.0 IDE is more powerful in comparison. On the other hand, you have tight integration of the host application in VBA. Application-global objects (like "ActiveDocument") and events are available without declaration, so application-specific programming is straight-forward.

Still, nothing keeps you from firing up Word, loading the VBA IDE and solving a problem that has no relation to Word whatsoever. I'm not sure if there is anything that VB 6.0 can do (technically), and VBA cannot. I'm looking for a comparison sheet on the MSDN though.

The scope qualifiers Public and Friend determine whether clients in different projects can see the item.

• Public items will be accessible to client code in other projects¹ and code in the same project.
• Friend items are accessible only to code in the same project, not to code in other projects.
• Private items are accessible only to code in the same class.

Properties are different from public variables, because with properties you can execute your own code when the client gets or sets the value². EDIT following Deanna's comment: Also note that variables can be passed ByRef to a function and changes will work as expected. This is NOT the case for properties.

NB C# may be more modern, but IMHO the VB6 treatment of properties and public variables is significantly better than the .Net treatment.

• In VB6 you can change a public variable into a property without breaking the clients. You don't even have to recompile them. Not true in .Net.
• In VB6 public variables can be used with data binding. Not true in .Net.
• In VB6 public variables could be used with interfaces. Not true in .Net.

IMHO Microsoft made a real design mistake in creating these differences between properties and public fields in .Net. Not convinced? After the first releases of .Net, the C# and VB compilers were modified to support automatically implemented properties. These allow you to create properties in just one line of code, so that it's later possible to add logic on get/set without causing problems. IMHO this proves that public variables should have been made indistinguishable from properties.

_{1 Assuming your project type actually allows your classes to be used by other projects (i.e. ActiveX DLL, OCX, or ActiveX exe).
2 In the Property Get, Property Let and Property Set procedures.}