What to do when VB controls fail to import in C++Builder 4

I have got a Access Violation problem with an VB activex in a Borland C++ 4
and I found the following article to solve the problem but I dont have solve
my problem because I dont know where and how to apply the solution or I dont
understand it.

Someone help me explaining it with a example. Thank you.

Sorry for my poor english.

The article:

The Problem: Certain ActiveX controls created in Visual Basic 5.x and 6.x
import unsuccessfully under C++Builder, and attempts to use the client-side
wrapper code result in access violations at runtime.

The Causes of the Problem: Certain controls do not conform to the expected
behavior of COM objects with respect to internal layout. COM specifies that
methods of interfaces should be layed out sequentially, and that interfaces
can be treated as being synonomous in implementation with C++ virtual
tables. C++Builder, accordingly, assumes during importation that this is the
case. Unfortunately, certain controls in fact expose interfaces in which
methods are not layed out sequentially, and as a result there are "gaps" in
the resulting vtables which are not taken into account. As a result, while
the client-side wrappers generated by C++Builder map methods incorrectly,
and calls to the incorrectly mapped methods AV.

How C++Builder 4 Patch 1 solves the Problem: After the patch is applied,
C++Builder's import logic can correctly detect gaps in the vtables of COM
interfaces (so-called "sparse vtables"), as long as the gap is not at the
beginning of the interface. Thus, reimporting the control or server after
the patch is applied will solve the problem in most cases. In those cases
where the gap is in fact at the beginning of the interface, C++Builder is
not able to detect it, and the generated wrappers will fail at runtime.

Using Dispatch to get around the problem: Because the problem is related to
non-conformant interface layout, the symptoms only appear when interacting
through a vtable interface (also known as early binding). Using
IDispatch::GetIDsOfNames to retrieve a DispID, and then passing it to
IDispatch::Invoke, will allow you to workaround the problem.

How C++Builder 4 Patch 1 enhances the workaround: Using IDispatch, however,
disables the use of wrapper classes, including the TOleControl wrapper which
allows the control to be embedded as a component on a form. C++Builder 4
Patch 1 provides an undocumented feature that forces the importer to use the
dispinterface rather than the vtable interface when generating the wrapper
classes. This results in degraded performance (which is why the classes use
the vtable interface by default), but will allow the use of wrapper classes
in cases where there are vtable gaps at the beginning of an interface.

To generate wrapper classes which use the dispinterface, run:
tlibimp -C+ -P- -@+ [foo.ocx]
where -C+ specifies that C++ output should be enabled, -P- specifies that
Pascal output should be suppressed, and -@+ specifies that the dispinterface
should be used in wrapper classes.