What does this IDL record mean?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

alexey_yumashin - 27 Sep 2007 15:26 GMT

I have 2 "ActiveX DLL" VB6-projects referencing each other. The
referring project has been created years ago and hasn't been changed
all this time. The referenced project has been changed often; to say
more exactly - its interfaces have been extended several times (new
public classes and public members of existing classes has been added
several times).

Today I decided to make minor changes (not touching interfaces) in the
_referring_ project. This gonna be the first change in this project
during the last several years. I opened it in VB IDE, made some
changes and clicked "Make...". The following error appeared
immediately:

"Variable uses an Automation type not supported in Visual Basic"

When after 2 or 3 hours struggling with this error I decided to view
typelib of this project in the "OLE Viewer", I saw the following (I
omit all members except the one under question):

typedef [uuid(3B34ABCA-8468-4C73-BAA2-3881285DB782), version(1.0)]
struct tagIDate {
< omitted >

[helpstring("g_adoc")]
clsADOConnection___v3* g_adoc;

< omitted >
} IDate;

(here clsADOConnection is the name of one of the classes defined
inside the referenced project)

My question is: what does this mean - "clsADOConnection___v3" ? I mean
- why "___v3" in the end ? I can suppose that it's the typelib
version, but I can't understand why it is explicitly referenced. The
point is that if I view IDL of _other_ VB6-projects referencing the
same clsADOConnection class, I'll see the following:

[helpstring("member")]
_clsADOConnection* member;

The most interesting thing is that I managed to fix the error only in
the following manner: I changed "Version compatibility" to "No
compatibility" in the properties of the referring (!) project,
compiled it (no error occured this time!), then changed "Version
compatibility" back to "Binary compatibility" and recompiled it again.
After that checked the recompiled DLL in the OLE Viewer - and yes!
"clsADOConnection___v3" changed at last to "_clsADOConnection"!

(of course this approach pushed me to fix references in all dependant
projects, but it was not a problem)

I just wonder what's this all about... any _expert_ opinion will be
greatly appreciated!

Reply to this Message

Ken Halter - 27 Sep 2007 15:40 GMT

>I have 2 "ActiveX DLL" VB6-projects referencing each other. The

Always scary. If VB detects you have a circular reference, it won't compile.
You can see that by opening both projects in the same instance of the IDE
(as part of a project group)

> more exactly - its interfaces have been extended several times (new
> public classes and public members of existing classes has been added
> several times).

Every time you add a new public member, even if it's just another member of
an Enum, the compatibility model absolutely must be updated. Any public
members that aren't present in your model will generate all new IIDs for
those members each time you compile, regardless of changes made to the code.
In fact, no code changes required to break compatibility.

> changes and clicked "Make...". The following error appeared
> immediately:
>
> "Variable uses an Automation type not supported in Visual Basic"

Sounds like a mixture of the problem above (new IIDs not present in the
model) and a dirty registry. Registry garbage can break a DLL, eve if
there's nothing wrong with the DLL itself. I use RegClean once in a while
and System Mechanic to keep the registry clean.

> clsADOConnection___v3* g_adoc;

The v3 means 3 changes were made to the interface since compatibility was
set up. There's no problem with that, as long as the IIDs aren't changing
all the time.

> same clsADOConnection class, I'll see the following:
>
> [helpstring("member")]
> _clsADOConnection* member;

Those projects were compiled against the original release of the DLL(s)
you're working with. That's all normal too.

> After that checked the recompiled DLL in the OLE Viewer - and yes!
> "clsADOConnection___v3" changed at last to "_clsADOConnection"!

Next time you add a public member, the number will be incremented.

> (of course this approach pushed me to fix references in all dependant
> projects, but it was not a problem)

Here's a page that describes compatibility settings.... or, at least tries
to <g>

Binary Compatibility
http://www.vbsight.com/BinaryComp.htm

Signature

Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
In Loving Memory - http://www.vbsight.com/Remembrance.htm

Reply to this Message

alexey_yumashin - 27 Sep 2007 18:42 GMT

> >I have 2 "ActiveX DLL" VB6-projects referencing each other.
>
> Always scary. If VB detects you have a circular reference, it won't compile.
> You can see that by opening both projects in the same instance of the IDE
> (as part of a project group)

Sorry for misprint. Not "each other", but just a reference from one to
another. So no any circular reference indeed.

> Sounds like a mixture of the problem above (new IIDs not present in the
> model) and a dirty registry. Registry garbage can break a DLL, eve if
> there's nothing wrong with the DLL itself. I use RegClean once in a while
> and System Mechanic to keep the registry clean.

I got used to clean registry too. I did it this time as well. Didn't
help!

> > clsADOConnection___v3* g_adoc;
>
> The v3 means 3 changes were made to the interface since compatibility was
> set up. There's no problem with that, as long as the IIDs aren't changing
> all the time.

I can bet that interfaces have been extended much more than 3 times!

> Those projects were compiled against the original release of the DLL(s)
> you're working with. That's all normal too.

Hm... that's not right. Very small number of projects was compiled
against the original release!

Reply to this Message

Ken Halter - 29 Sep 2007 03:31 GMT

> Hm... that's not right. Very small number of projects was compiled
> against the original release!

Well... I'm not sure what tools you're using to compile the projects, but
typlib versions and what they represent, are pretty consistant.
But, thinking about it more, I'd almost bet some dependency is missing or
broken somewhere in the chain.

To clear it up for good, you can unregister *every* dll involved in the
entire project (not counting OS related dependencies), reinstall ADO support
(that may be the culprit right there)... *after* that, start compiling your
projects in reverse dependency order (exe needs dlla needs dllb, compile
dllb first, then dlla, then the exe)....

Plus, before going on to the next project, set aside your compatibility
model, setup binary compatibility and recompile (it only takes a second,
after all). This sets up a sort of secondary interface that lets other
components know what to expect. Some environments *require* this extra step
(RSView for one) and they won't recognise the component until you've
recompiled with binary compatibility set.

fwiw, I recommend compiling with only a single project loaded in the IDE.
While it's possible to setup a group so it compiles in a specific order,
there's nothing preventing VB from updating that group project file when
ever it wants.

If none of that helps, get a rubber hammer and start beating the side of
your PC <g>

Signature

Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
In Loving Memory - http://www.vbsight.com/Remembrance.htm

Reply to this Message

VB Forum / COM / September 2007

What does this IDL record mean?