Vb Classic Bugs

Bugs in VbClassic (VisualBasic versions up to 6, but not including VisualBasicDotNet):

[[BadImplementsRefInCompatLib?]] / [[BadImplementsReflnCompatLib?]] Error Message:

A VisualBasic 6.0 compiler bug:

Microsoft Article ID Q190078:: BUG: Error "[[BadImplementsRefInCompatLib?]]" When You Recompile a Server That Contains a Project Compatible DLL

http://support.microsoft.com/support/kb/articles/Q190/0/78.ASP

Symptom:: The highly informative "[[BadImplementsRefInCompatLib?]]" error message.

When one project implements an interface defined in another project, and the project defining the interface loses binary compatibility, you can no longer compile projects implementing the interface.

Workaround: In the project(s) getting the "[[BadImplementsRefInCompatLib?]]" error, drop from binary to project compatibility, recompile, and then go back to binary compatibility. (Then you have to recompile all projects that use them.)

What MicroSoft's "Q190078" article fails to mention is that you can get this error even if you strictly adhere to binary compatibility rules: If you change an interface in a way that makes it incompatible, VisualBasic correctly drops old GUIDS and assigns a new GUID to the interface. This also triggers the "[[BadImplementsRefInCompatLib?]]" error message.

(Not to mention some MicroSoft help desk person who typed "Ref<lowercase-ell>n" instead of "Ref<uppercase-eye>n". ;-)

This VbClassic problem remains present, even in service pack 6.

Conditional compilation disabled method implementation check:

In VisualBasic 6.0 (SP4), conditional compilation of method implementations in a class disables VisualBasic's check that you implemented all the methods of the interface.

(Since all methods of VisualBasic interfaces are "pure virtual" in the C++ sense, you have to implement all of them to have a valid (IE: non-crashing) program.)

Example: Create a new project, a "Standard EXE."

Add a class. Call it "I1". Put this in it:

 Option Explicit
 Public Sub a()
 End Sub
 Public Sub b()
 End Sub

Add another class. Leave it called "Class1". Put this in it:

 Option Explicit
 Implements I1
 Public Sub I1_a()
   Debug.Print "Now in I1_a()."
 End Sub
 #If 0 Then
 Public Sub I1_b()
   Debug.Print "Now in I1_b()."
 End Sub
 #End If

VisualBasic gave you a form. Give it a Form_Load event:

 Option Explicit
 Private Sub Form_Load()
   Dim i As I1
   Set i = New Class1
   Call i.a
   Call i.b       ' This call crashes VisualBasic
   Unload Me
 End Sub

Run it. VisualBasic and the IDE will crash on "Call i.b", because there is no code behind that method.

I get...

 vb6.exe - Application Error
 (X) The instruction at "0x00000000" referenced memory at "0x00000000". The memory could not be "read".
     Click OK to terminate the program
     Click CANCEL to debug the program
             [OK] [Cancel]

(This bug caused me trouble in EnhancingVbUnit. -- JeffGrigg)

Public Form variables break binary compatibility:

In any VisualBasic ActiveX project,

if your project exposes any public variable of type 'Form',
and you adhere to "binary compatibility,"
then you will be warned every time that you're breaking compatibility, and there's no way you can avoid it.

(Fortunately, it appears that you aren't really breaking compatibility, so don't worry about it. ;-)

Example:

Create a new "ActiveX DLL" VisualBasic project.
Type this line, "public mForm as Form" in Class1.
"Make Project1.dll..."
In "Project -> Project1 Properties..." on the "Component" tab, change Version Compatibility from Project Compatibility to Binary Compatibility.
"Make Project1.dll..." and replace.

Congratulations:

 'mForm' in the 'Class1' class module has arguments and/or a return type
 that is incompatible with a similar declaration in the version-compatible
 component.

 Original definition:
  Public mForm As Object

 Current definition:
  Public mForm As Form

 'mForm' in the 'Class1' class module has arguments and/or a return type
 that is incompatible with a similar declaration in the version-compatible
 component.

 Original definition:
   Property Set mForm(ByVal RHS As Object)

 Current definition:
  Public mForm As Form

  Your application is incompatible with C:\...\Project1.dll.
 The project name and the .EXE filename for both applications are the same. Change the Project
 Name setting in the Project Options dialog box and use a unique name for the current .EXE file.
 You can see the specific incompatibilities by returning to design mode and running the project.

Line Continuation and Date Constants Don't Mix:

A VisualBasic 6.0 IDE bug: Date constants and line continuation don't mix.

Type this into the IDE:

    Const dt As Date = _
        #1/1/2001#

it automatically changes your code to this:

    Const dt As Date = # _
        1/1/2001#

DING! Syntax error. Try to fix it, and VB breaks it again.

Workarounds:

    Const dt As Date _
        = #1/1/2001#

    Const dt As Date = _
        CDate(#1/1/2001#)

Const dt As Date = _ 0 + #1/1/2001#

This is actually a common class of bug in code formatters, to change the formatting such that it breaks some obscure or inconsistent rule in the syntax of the language. It's especially common (although not necessarily a bug any more) with formatters which are very configurable + lint-like things. --WilliamUnderwood

Other VbClassic Bugs:

CategoryVbClassic