ODL Compile Problems Revisited

[mikie]

I have several large workspaces consisting of a number of projects. Each project has it's own .fp.

Most projects compile their DLLs without problem whether in debug or release.

I have a couple of projects that can't create the DLL in release, but will in debug, only after deleting the cvibuild directory.

I have one library I'm trying to build that suddenly won't compile without this error regardless of the build configuration or if I have deleted the cvibuild directory.

The ODL error of course, is:

Error generating type library. Midl.exe failed while compiling the odl file used to create the type library.

Note: The error indicates that the odl file has unknown types. This error is possible when functions with non-standard types are exported using the export qualifier method from files in release configuration that have not been recompiled during the build process. You can mark all files for recompilation and repeat the build. To avoid this situation, it is recommended that you export these functions using the include file method.

blah, blah, blah.

The list of non-standard types may be quite long, so can anyone tell me what the "standard" types supported are?
I've reviewed my types and they all look quite standard to me.

I believe that I already export all my functions using include files. I wasn't aware there was any other method.

Can someone expand on that?

Mike

[mikie]

More info:

Here is a snippet from the ODL file.

        [helpcontext(95), entry("pGetFrequency"), helpstring("Get Frequency")]
        int __stdcall pGetFrequency(
            [in] int cage,
            [in] int slot,
            [in] int pin,
            [in] int object,
            [in, out, custom(53D57340-9A16-11d0-A62C-0020AF16F78E, 0), custom(746B27E1-FBD7-11d1-B311-0060970535CB, 1)] int *uiFrequency);
        [helpcontext(96), entry("pSetFrequency"), helpstring("Set Frequency")]
        int __stdcall pSetFrequency(
            [in] int cage,
            [in] int slot,
            [in] int pin,
            [in] int object,
            [in, custom(746B27E1-FBD7-11d1-B311-0060970535CB, 1)] int uiFrequency);


Are the last parameters of each of these functions "non-standard"?

One is a pointer to an unsigned int and the other is an unsigned int.

[mikie]

Here's another example.

This is the definition in the .fp

        iStatus = pGetActive (int Cage, int iSlot, int iPin,  unsigned int *iObject);

And here is the definition in the ODL file

        [helpcontext(42), entry("pGetActive"), helpstring("Get Active")]
        int __stdcall pGetActive(
            [in] int iCage,
            [in] int iSlot,
            [in] int iPin,
            [in, out, custom(53D57340-9A16-11d0-A62C-0020AF16F78E, 0), custom(746B27E1-FBD7-11d1-B311-0060970535CB, 1)] int *iObject);


So, is the ODL confused regarding the type of the last parameter, a pointer to an unsighed integer?

[mikie]

Repeat - I have several large workspaces consisting of a number of projects. Each project has it's own .fp.

Most projects compile their DLLs without problem whether in debug or release.

I have a couple of projects that can't create the DLL in release, but will in debug, but only after deleting the cvibuild directory.

I have one library I'm trying to build that suddenly won't compile without the following error regardless of the build configuration or if I have deleted the cvibuild directory.

The ODL error of course, is:

Error generating type library. Midl.exe failed while compiling the odl file used to create the type library.

Note: The error indicates that the odl file has unknown types. This error is possible when functions with non-standard types are exported using the export qualifier method from files in release configuration that have not been recompiled during the build process. You can mark all files for recompilation and repeat the build. To avoid this situation, it is recommended that you export these functions using the include file method.

blah, blah, blah.

The list of non-standard types may be quite long, so can anyone tell me what the "standard" types supported are?
I've reviewed my types and they all look quite standard to me.

I believe that I already export all my functions using include files. I wasn't aware there was any other method.

Can someone expand on that?

Mike

[mikie]

Nobody has ever had this problem?

Nobody has a list of "standard" data types

Are they the intrinsic ones?

Intrinsic C Data Types

The intrinsic C data types that LabWindows/CVI defines are as follows:

int
long
short
char
unsigned int
unsigned long
unsigned short
unsigned char
int []
long []
short []
char []
unsigned int []
unsigned long []
unsigned short []
unsigned char []
double
float
double []
float []
char *
char *[]
void *

[mikie]

What about

Int *
float *
double *

and so on, are they not "standard types"?

[herosphro]

Mikie,

It looks like the custom command is used when the MIDL compiler doesn't recognize a data type, so I believe you are correct in your conclusion about unsigned int * not being a default type.  Unfortunately there is not a very well layed out list of types that the compiler will recognize other than the Language Reference page (Note that the MIDL compiler is a Microsoft product so the information is found on MSDN).  If you look at the basic types (int, char, etc) it seems as though they are not compatible or usable as pointers by default, though unsigned integers are acceptable.  We may be able to use the ptr type but I am not as familiar with this command.

I think the best course of action is to try and replace the problem data types (unsigned int *) with recognizable types and see if we still get the error.  If we don't then we know its related to these parameters then we can simply work on getting those parameters fixed.  If we do still get an error we may need to conduct some further investigation.

[mikie]

Thanks John. That helps.

It made me wonder how anything I've written worked at all. I have pointers to different types in hundreds of functions in more than a dozen different libraries. (Only this one won't let me compile)

The MIDL compiler seems quite limited and restrictive.

But, I also have to ask...

I am only using the fp files as a help tool and for a documentation source.  Is there a way to turn off the ODL compiling? As if I had no fp at all? (libs, dlls, and  includes are all I really need anyway)

Mike

[mikie]

I was able to go Build >> Target Settings >> Type Library and turn off "Add Type Library Resource to DLL".

This turned off creating the ODL file from the function panel.

I compiled just fine.

This gets me around this problem, for now.

I don't actually need the type library in the DLL, do I?

[herosphro]

Mike,

The type library is not necessary to simply use a DLL with other programs.  Type libraries are used with DLLs when you are compiling the DLL to use as an ActiveX object.  The ODL file is used to help generate the type library, so as you mention without this file we can't generate a type library.  Therefore if you are just going to be using the DLL in direct calls from other programs and not as an ActiveX object you should have no problems.