How to fix "Unexpected error (32801)" when compiling VB 6 program ?

tags:

activex
vb6

views:

139

answers:

+3 Q:

How to fix "Unexpected error (32801)" when compiling VB 6 program ?

Hi all

I have to maintain an old VB 6 ActiveX DLL called by another 3rd party program for which I have no sources etc. This DLL works and compiles fine against the API of said program for about 6 years and 3 major versions.

But now when I try to compile the DLL against a new major version the mentioned error occurs. It seems the error occurs before "my" code is called so there´s no use debugging or logging. The only remedy was to compile w/o binary compatibility which is no real option. My Google search turned up quite some people with the same problem but no solution.

Does anybody here know how to fix this issue ?

Thanks in advance

banzai

There is a discussion about this error on devx.com that seems to indicate that the problem stemmed from Microsoft's Scripting Runtime (scrrun.dll).

FileSystemObject compatibility Unexpected error (32810)

Does your DLL reference that library? If so, can you remove the reference (e.g., replace FileSystemObject functionality with intrinsic VB file handling functions and/or API calls).

raven 2010-03-08 15:22:16

The project does not reference the MS library but the FileSystemObject is used via late-binding (CreateObject(...)). Do you really think this could be the cause of the error ? The post you mention above is from the year 2001. My code compiled fine til ~ December 2009 and there were absolute no code changes since then. I double-checked this in our versioning system. The only change is the new major version of the calling application.

banzai 2010-03-08 15:54:38

@banzai: Your code can break even if you haven't touched it in years. If one of its dependencies (e.g., the FileSystemObject) breaks, you can encounter strange errors like this. Is *your* problem actually related to the FileSystemObject? I don't know. Try removing all references to it and see if you still get that error. To test this, the code doesn't have to work, it just needs to compile, so you could first just comment out whatever you need rather than actually replacing the functionality of the FSO.

raven 2010-03-08 19:17:03

If the description in the question is correct, then I think the problem is caused by the 3rd party API changing its type library in an incorrect way. It looks from the link as if Microsoft once made a similar mistake with the FileSystemObject (if **Matthew Curland** says so, it must be true). Doesn't necessarily mean banzai's problem is caused by the FileSystemObject. It's unlikely that types from the FileSystemObject are included in banzai's public interfaces, but it's extremely likely that types from the 3rd party API are included in the public interfaces.

MarkJ 2010-03-09 09:12:19

Are any of the files associated with the core project being compiled marked as Read-Only (i.e. not checked out of SourceSafe or similar repository)?

*.exp *.vbw *.lib

jasonk 2010-03-08 17:05:50

All those temporary file types are not under version control. To make sure I "unprotected" everything and tried to compile - same error as before.

banzai 2010-03-09 09:43:16

It sounds like one of the types in the interfaces defined in your new DLL is different from one in the previous DLL. I'm deducing you use types defined in the third party program in your public interfaces of your DLL. It sounds to me like the third party has changed the definition of one of the types but kept the name and GUIDs the same. You could use something like OLE/COM Object viewer to check whether that's true. If it is true then you can complain to the publisher of the 3rd party program. Do you have enough political power to succeed?

Bruce McKinney, the guru who wrote Hardcore Visual Basic 6, ran into the same issue with a structure in a type library, where he changed some of the member types. The only fix he could find was (essentially) to break binary compatibility - and that's after some correspondence with the VB6 compiler team, who he knew fairly well. I don't think anyone else could do better.

MarkJ 2010-03-08 20:56:19

You have deduced right. I checked the old and new version´s IDL. They just differ in quite some helpstring comments and the addition of one new interface. The changes in helpstrings are of no relevance here but what about the new interface. I thought the ADDITION of a new interface wouldn´t break the binary compatibility. If it does I´ll have to call the mobsters and send them to my favourite 3rd party vendor ;-) ...

banzai 2010-03-09 09:51:50

I wouldn't have thought adding an interface would cause any problems. From reading the links it sounds like very subtle changes can cause this problem - like reordering the elements in a type or making apparently innocuous changes to data types.

MarkJ 2010-03-09 12:48:44

Me too - that has to be a VERY subtle change if that´s the cause of the error. No reordering or such, just one new interface. I think the FileSystemObject is an unlikely cause because I have no public types of it in my interface and object creation is by late-binding to avoid such compatibility issues known to be caused by old IE versions and the MS scripting library too. Because this is just a compile-time issue I´ll leave everything unchanged - code compiled against older versions runs fine with the new major version of the calling application. Too much effort to continue here.

banzai 2010-03-09 13:45:44

ansaurus

tags:

views:

answers:

How to fix "Unexpected error (32801)" when compiling VB 6 program ?

related questions