VB Compatibility Problem: Complete Refusal To Compile

[Bloggs.Fred]

We've got a relatively large OCX that's been evolving over quite a long
time. Just recently, VB has decided that it no longer wants to compile
with Binary Compatibility set and reports a rather improbable error
along these lines:

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

Original definition:
Public flags As Object

Current definition:
Public flags As FlagsSelect


I say improbable because, since the dawn of time, flags has always been
public and always of type FlagsSelect.

From here there are two possible options available: change the

declaration to fit in with VB's confused view of the universe or keep
the declaration as it is, break compatability and move on.
Trying the latter option first, we switched off compatibility,
generated an OCX, copied that into the compatibility directory, and
switched compatibility back on selecting the fresh OCX. Problem is, VB
just spits out exactly the same complaint.

The only way we've found to get a binary built without VB complaining
is to alter the declaration to "Public flags As Object". It's almost
as if VB is sticking its head in the sand and saying that even though
it knows its error message is a lie, it's going to make it a truth by
having you change your code anyway!


Anyone got any clues as to what this is all about? Will it ever be
possible to build the source code as it was or do we have to play along
with VB? Why do I have visions of HAL9000 running through my head?

[Ken Halter]

Post by Bloggs.Fred
We've got a relatively large OCX that's been evolving over quite a long
time. Just recently, VB has decided that it no longer wants to compile
with Binary Compatibility set and reports a rather improbable error

Where does 'FlagsSelect' come from? Do you have an older copy of the OCX
that contains >all< public methods?

If you want, you can download a demo of my ComGuard add-in and compare
typelibs that exist in a new version and an old version of that OCX.

ComGuard
http://www.vbsight.com/ComGuard.htm


...and, this is a 'bare bones' compatibility page. If you've ever
re-compiled after adding a new public interface but forgot to update your
model... well... that's when the fun begins <g>

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

[Bloggs.Fred]

Post by Ken Halter
Where does 'FlagsSelect' come from?

FlagsSelect comes from another in-house OCX - we've been building
against the same version of that OCX for probably a year or more.

Post by Ken Halter
Do you have an older copy of the OCX that contains >all< public methods?

Everything's source controlled and yes, there are various older copies
of the OCX available.

Post by Ken Halter
If you want, you can download a demo of my ComGuard add-in and compare
typelibs that exist in a new version and an old version of that OCX.

I'll have a go at that. Thx.

[Ralph]

Post by Bloggs.Fred
We've got a relatively large OCX that's been evolving over quite a long
time. Just recently, VB has decided that it no longer wants to compile
with Binary Compatibility set and reports a rather improbable error
'flags' in the 'CtlFlags' class module has arguments and/or a return
type that is incompatible with a similar declaration in the
version-compatible component.
Public flags As Object
Public flags As FlagsSelect
I say improbable because, since the dawn of time, flags has always been
public and always of type FlagsSelect.

From here there are two possible options available: change the

declaration to fit in with VB's confused view of the universe or keep
the declaration as it is, break compatability and move on.
Trying the latter option first, we switched off compatibility,
generated an OCX, copied that into the compatibility directory, and
switched compatibility back on selecting the fresh OCX. Problem is, VB
just spits out exactly the same complaint.
The only way we've found to get a binary built without VB complaining
is to alter the declaration to "Public flags As Object". It's almost
as if VB is sticking its head in the sand and saying that even though
it knows its error message is a lie, it's going to make it a truth by
having you change your code anyway!
Anyone got any clues as to what this is all about? Will it ever be
possible to build the source code as it was or do we have to play along
with VB? Why do I have visions of HAL9000 running through my head?

I wonder if this error might be bogus. Not that you aren't getting a
warning, but that the true cause is not that declaration.

You said that you copied the ocx into a "compatibility directory", so I
assume you are avoiding any issues with maintaining compatibility with the
same component you are replacing.

I would definitely use Ken's tool, but if it still has problems, it is
possible file size and total symbols might be too much. You might try
removing a few methods and/or reordering them and see if the error moves.

Rummage through the references and insure everything is as it was.

hth
-ralph

[Bloggs.Fred]

Post by Ralph
I wonder if this error might be bogus. Not that you aren't getting a
warning, but that the true cause is not that declaration.

I'm sure this is the case. Probably an 'On Error Resume Next'
somewhere in VB :D

Post by Ralph
it is possible file size and total symbols might be too much.

I've wondered about this possibility too but..

[Robert Morley]

Another thing you might want to try as a last resort is to scan through the
.bas (.cls, etc.) files--particularly the ones with the declaration of flags
and the definition of FlagsSelect--with a regular text editor. I've seen
certain oddities crop up due to either non-text characters having somehow
being inserted into the file, or invalid settings having crept into the
metadata.


Rob

Post by Bloggs.Fred
We've got a relatively large OCX that's been evolving over quite a long
time. Just recently, VB has decided that it no longer wants to compile
with Binary Compatibility set and reports a rather improbable error
'flags' in the 'CtlFlags' class module has arguments and/or a return
type that is incompatible with a similar declaration in the
version-compatible component.
Public flags As Object
Public flags As FlagsSelect
I say improbable because, since the dawn of time, flags has always been
public and always of type FlagsSelect.

From here there are two possible options available: change the

declaration to fit in with VB's confused view of the universe or keep
the declaration as it is, break compatability and move on.
Trying the latter option first, we switched off compatibility,
generated an OCX, copied that into the compatibility directory, and
switched compatibility back on selecting the fresh OCX. Problem is, VB
just spits out exactly the same complaint.
The only way we've found to get a binary built without VB complaining
is to alter the declaration to "Public flags As Object". It's almost
as if VB is sticking its head in the sand and saying that even though
it knows its error message is a lie, it's going to make it a truth by
having you change your code anyway!
Anyone got any clues as to what this is all about? Will it ever be
possible to build the source code as it was or do we have to play along
with VB? Why do I have visions of HAL9000 running through my head?