Module generated by the Module Wizard won't compile - MS ASO 2.6

[monarchi]

I used the module wizard to generate a module for Microsoft ActiveX Data Objects 2.6 Library (msado26.tlb). When I try to compile the module, I get the following error 8 times.

Error: There is no matching specific subroutine for this generic subroutine call. [AUTOADDARG]

The lines of code that it occurs on are similar to the following.

CALL AUTOADDARG(invokeargs, 'NumericScale', $RETURN, AUTO_ARG_OUT)

What am I missing here? Is some step necessary between creating the module and compiling it?

Thanks in advance,
david

[monarchi]

Sorry, the title should have been MS ADO 2.6, not ASO.

[Steven_L_Intel1]

What compiler and version are you using? I just tried this with Intel Visual Fortran 9.0 and it worked ok.

The error means that the arguments in the call don't match, by number, datatype or kind, those of any of the procedures in the generic interface.

[monarchi]

Sorry, Steve. I should have included that information.

I'm using Version 9.0.2713.2003 with VS.Net 2003 Professional/Academic. The OS is XP Pro with all current updates/patches.

What library contains AUTOADDARG? Perhaps I need to add something to the command line parameters or to the library list.

Thanks for your help.

david

[Steven_L_Intel1]

It's in IFAUTO, but the fact that you got the message about the generic tells you that it found the definition. Do you have any non-default compiler options specified? Did you just now generate this module or is it an old one you had lying around?

What you need to do is look at the source of the module where these calls are made, determine the datatype and kind of each argument, and then compare that to the various specific procedures found in IFAUTO.F90 (in the INCLUDE folder) to see why the appropriate specific procedure was not matched.

[monarchi]

Thanks for the quick response, Steve.

To the best of my knowledge, everything is as vanilla-flavored as it can be. I created a new dummy solution yesterday just to try this out. The solution, source file, and program are all named the same: DeleteDelete. The body of the program consists of three non-comment lines:

program DeleteDelete
implicit none
! Variables

! Body of DeleteDelete

end program DeleteDelete

The command line options are
/nologo /Zi /Od /module:"$(INTDIR)/" /object:"$(INTDIR)/" /traceback /check:bounds /libs:static /dbglibs /c

I suspect I've overlooked something painfully obvious, but I don't see it.

Thanks,
david

[Steven_L_Intel1]

Hmm. Well, at this point, please submit an issue to Intel Premier Support, attach a ZIP of your project and ask that it be assigned to Steve Lionel. I'll compare with my own test case and see what's up.

I ran into an issue similar to this when using an older generated module, but regenerating the module made it go away.

[monarchi]

Hi Steve -

I believe I've identified the cause, but I want to make certain I understand the problem. Please bear with me for a moment.

In creating the module with the wizard, there are 3 check boxes and a total of six combinations because some are constrained.

I created and tried to compile all combinations with the following results:

Nothing checked - compiled

Generate code that uses Automation interfaces - did not compile

Generate DLLEXPORT statements - compiled

Automation interfaces and exception return status - did not compile

Automation interfaces and DLLEXPORT statements - did not compile

Automation interfaces, exception return status, and DLLEXPORT statements - did not compile

Clearly the problem is related to creating Automation interfaces.

Then I remember that I created this test as a console application. Does that mean that I can't ask for the automation interfaces to be created even if I won't use them?

Thanks for your patience. I'm very old at Fortran (Fortran II in the 60s), but very, very new to the .COM and .NET world.

Please let me know if I'm correct. Thank you.

cheers,
david

[Steven_L_Intel1]

David,

I saw your report to Intel Premier Support and sent you a reply. The problem is caused by a handful of Automation interfaces that return INTEGER(1) values. Our automation library does not provide for that type. I suggested a workaround, and will ask that the library be enhanced.